2012-11-30 15 views
5

Stiamo benchmark Symfony2 con Doctrine2 vs ZendFramework2 con Doctrine2.Si prega di spiegare questo Symfony2 vs risultati prestazioni ZendFramework 2

Il test consisteva in un semplice Hello World ZF2 e SF2 per i valori di base vs. lo stesso ma con Doctrine2 che carica un oggetto semplice. Abbiamo usato ab e misurato solo le richieste al secondo e il tempo per richiesta.

Durante il test del framework nudo Hello World ZF2 ha ottenuto prestazioni migliori rispetto a SF2 quasi 2x.

Tuttavia, quando abbiamo eseguito lo stesso test ma aggiungendo Doctrine2 nel mix, i risultati sono stati invertiti. SF2 + D2 si è comportato 2x velocemente come ZF2 + D2.

Abbiamo competenze in-house sia per Symfony2 che per ZendFramework, così potremmo optare per l'uno o l'altro, e non ci preoccupiamo dell'utilizzo della RAM dato che possiamo sempre ottenere più RAM. Ma ci importa delle prestazioni e abbiamo bisogno di aiutare lo strumento migliore.

Alcune idee: - Crediamo S2 sta facendo una sorta di caching - Crediamo ZF2 Doctrine2 ORM modulo potrebbe essere la causa - Siamo sicuri che tipo di caching da utilizzare per la produzione? APC? XCache? ecc

Framework + Doctrine loading an object  
Concurrent:100/Connections: 1000  
    Resp. T ms Req. Sec 
ZF2  60 16 
S2   31 32 

Framework + Doctrine loading an object  
Concurrent: 25/Connections: 150  
    Resp. T ms Req. Sec 
ZF2   57 17 
S2   30 32 


====================== 

Framework Bare  
Concurrent: 100/Connections: 1000  
    Resp. T ms Req. Sec 
ZF2   10.5 94 
S2   15.3 65.36  

Framework Bare  
Concurrent: 25/Connections: 150  
    Resp. T ms Req. Sec 
ZF2   10 98 
S2   15.4 64 
+2

Il mondo ciao era una linea di base per il modo in cui ogni quadro si comporta fuori dalla scatola e ottenere una prima misurazione delle capacità computer e la configurazione di apache desiderato. I test hanno coinvolto molti altri test, ma stavo solo citando i più rilevanti. Abbiamo eseguito test a basso, medio e alto volume, concurrent, single, local, remote, hello world, caricando 100, 1000, 10000 oggetti, iterazioni, etc etc etc ...Non è che possiamo costruire un'intera applicazione in entrambi i framework solo per i test, quindi stiamo facendo il possibile prima di iniziare lo sviluppo. – smorhaim

risposta

7

Per impostazione predefinita, l'integrazione DoctrineORMModule ha nessun tipo di caching attivo.

è necessario impostare la cache per le mappature nella configurazione:

'doctrine' => [ 
    'driver' => [ 
     'orm_default' => [ 
      'class' => 'Doctrine\ORM\Mapping\Driver\DriverChain', 
      'drivers' => [], 
      'cache' => 'apc', 
     ], 
    ], 
], 

La cache di default è array. Altrimenti, l'analisi di annotazioni e qualsiasi altro tipo di mapping avverrà ad ogni richiesta.

Poiché sono anche il manutentore dell'integrazione ZF2-Doctrine2, potrei anche essere interessato a saperne di più su questo argomento. Hai un ambiente di prova da mostrare?

+0

Oh ok .. proveremo ancora con queste impostazioni. Abbiamo implementato una piccola applicazione utilizzando ZF2D2 e si è bloccata terribilmente consumando molta più memoria di quella che avevamo assegnato per questo e abbiamo dovuto eseguire il rollback ... ecco perché lo stiamo facendo - d'altra parte abbiamo un enorme database intenso applicazione (con replica cluster master DB multi-master) con utilizzo da basso a moderato in produzione per 6 mesi e funziona molto bene ... Sì, abbiamo un ambiente di test. Avete altri suggerimenti o idee su come testare questo? Vogliamo fare il test delle mele quanto più possibile. – smorhaim

+0

Il suggerimento è di condividere la configurazione per il tuo "ciao mondo con un'entità". Meglio se come un piccolo modulo :) – Ocramius

+0

Inoltre, si noti che la distribuzione di qualsiasi cosa senza una cache di metadati è pura follia. L'analisi dei metadati comporta MOLTE operazioni di riflessione e scansione del codice. – Ocramius

0

Con il corretto caching di opcode (APC) e delle richieste DB (ad esempio con Memcache), direi che la differenza tra Synmfony e Zend sarà noccioline.

Non scegliere mai un quadro a causa di una così piccola differenza di perf. Otterrai molti più errori con la memorizzazione nella cache e miglioramenti DB che sul framework.

A meno che non si stia costruendo un'app in tempo reale per le finanze o una differenza di 10 o 20 ms nel tempo di risposta non è nulla. Il tempo medio di risposta per una pagina web è in genere in 100s di ms!

Inoltre, la conversione di un tempo di risposta in un "numero di richieste al secondo" non ha senso, anche se so che questo è comune nei benchmark PHP. Poiché il tuo Apache non tratterà le richieste in modo sequenziale (una richiesta non consuma CPU al 100%), le 5 richieste che arrivano nello stesso momento verranno pubblicate in meno di 5 volte la volta di una richiesta.

Come ha detto Ocramius, si dovrebbe attivare la cache dei metadati:

$frontendOptions = array(
     'lifetime' => 7200, // seconds 
     'automatic_serialization' => true 
    ); 

    $backendOptions = array(
     'cache_dir' => APPLICATION_PATH_CACHE 
    ); 

    $this->cache = Zend_Cache::factory('Core', 
           'File',//Memcache is better 
           $frontendOptions, 
           $backendOptions); 

    //ADD a metadata cache for DB, important for perf 
    Zend_Db_Table_Abstract::setDefaultMetadataCache($this->cache); 
+0

L'esempio che hai incollato non ha nulla a che fare con Doctrine 2 ORM ... – Ocramius

Problemi correlati