Ottimizza le mie prestazioni

Question

Sto lavorando a un progetto con Zend Framework 1.11, Doctrine 2, alcuni componenti di Symfony 2 e altri strumenti & librerie.

Sto cercando di ottimizzare le prestazioni utilizzando Xdebug & Webgrind.

Ho già trovato alcuni colli di bottiglia come l'analisi di Ini config, ecc. E memorizzato nella cache.

Ora, mi rendo conto che solo il caricamento automatico è la parte più costosa della mia applicazione:

Opl\Autoloader\ApcLoader->loadClass     274 31.36 43.86 
    Zend_Loader_PluginLoader->load       150 4.80 12.29 
    Zend_Loader_Autoloader->getClassAutoloaders   278 1.42 1.91 
    Zend_Controller_Router_Route_Regex->_getMappedValues 291 1.29 1.35 
    Doctrine\ORM\UnitOfWork->createEntity     85 1.24 3.18 

Come potete vedere non sto usando il default Zend_Loader_Autoloader, sto usando Opl che è, come per quanto ne so, più veloce di così, sto usando il classMapLoader con una cache APC ma rallenta ancora un po 'rispetto al resto dell'applicazione.

Come potrei ottimizzare?

Ho circa 250 classi caricate, e sembra che solo ~ 40 siano lente, altre mostrano 0,00 come "Costo totale chiamate" ma altre sono in aumento da 0,08 a 0,57 sulla chiamata richiesta.

A proposito, da quando utilizza il caricatore automatico Opl, sembra che nel mio ambiente di produzione APC solo opcode memorizzi nel cache i file che sono "manualmente richiesti" e non quelli che vengono chiamati dal caricatore automatico.

Answer 1

Se il refactoring del codice non è un'opzione (rilascia Zend Framework, Drop Doctrine, Drop ...) vorrei innanzitutto ottimizzare l'acquisto di hardware migliore. Questo ottimizzerà automaticamente il tuo codice, perché il contesto del codice è appena spostato (questo non sta esattamente ottimizzando il codice, poiché il codice non cambierà).

Se questa non è un'opzione, è consigliabile creare un sistema di generazione che possa pre-elaborare il codice base e creare una versione non di sviluppo per ridurre il processo di caricamento. Ciò richiede l'analisi di quali file sono sempre necessari e li si compila tutti in un formato ottimizzato per il caricatore che potrebbe essere un singolo file e/o mappe caricatore di classi statiche.

Tuttavia è noto che Zend ha bisogno di caricare molto in memoria sempre. Anche l'utilizzo di una cache PHP come APC potrebbe già portarti qualcosa (prendere in considerazione la precompilazione con lo script di build annotato in precedenza e ottimizzare le parti evidenziate dalle metriche).

Se la struttura dell'applicazione lo consente, c'è anche un'altra possibilità: mantenere l'intera applicazione in memoria tra le richieste. Questo può essere fatto con un webserver PHP. Fatto ciò, il codice deve essere caricato solo all'avvio del server e non sarà più necessario caricarlo di nuovo. Funziona solo con la tua applicazione se supporta più richieste. Una buona applicazione incapsulata, in particolare con la logica della richiesta, può essere adottata abbastanza facilmente. Una soluzione esistente è appserver-in-php. Sarai sorpreso di quanto aumenti la velocità rispetto ai vantaggi che hai già acquisito da APC.

Forse è stato utile. Eventuali suggerimenti aggiuntivi e più concreti sono difficili da realizzare in quanto non è possibile vedere il tuo codice in azione né avere metriche dettagliate su di esso. Hai appena passato un frammento su cosa sta succedendo dietro le quinte, quindi è difficile dirti più concretamente.

Answer 2

Non mi piace quello che hakre sta suggerendo. Prima di tutto vorrei vedere se posso rilasciare il server web. Se è così una buona alternativa è nginx o lighttpd. Rispetto ad Apache sono di questo secolo e anche la configurazione è molto più semplice.Informazioni sul caricamento automatico non lo so, ma se i file di classe sono veramente grandi hai provato a installare un ram disk o usare un compressore php? Nella mia esperienza, un compressore PHP può velocizzare significativamente il tempo di esecuzione (cioè il tempo di analisi).

Answer 3

Sto cercando di ottimizzare le prestazioni utilizzando Xdebug & Webgrind

OK, visto che sei in una posizione di grave che necessitano di migliori prestazioni, si potrebbe essere aperto a un meno popolare, ma dimostrabile efficace, modo per farlo.

Funziona con qualsiasi lingua, purché ci sia un debugger che può essere messo in pausa, come Xdebug.

Qui è descritto in a nutshell. Here's one demonstration of its effectiveness. Posso collegarvi molti di più.

Si potrebbe trovare un po 'intellettualmente strappo. Come in

1. Stai riscontrando "colli di bottiglia" come tempi associati alle routine. Le opportunità di accelerazione più preziose spesso non si manifestano in questo modo. Sono attività che potresti facilmente descrivere quando le vedi, ma sono diffuse. Non concentrano il tempo significativo in alcuna particolare routine o linea di codice, quindi i profiler non li vedono.

2. Le maggiori opportunità di speedup potrebbero non essere affatto facili da risolvere. Possono richiedere un ripensamento su come è organizzato il programma. Se trovi qualcosa che puoi facilmente risolvere, è grandioso. Vai avanti e fallo. Se non è così facile da risolvere, ma risparmierai ancora un sacco di tempo, se devi salvare quel tempo, devi farlo, che ti piaccia o no.

Buona fortuna.

Answer 4

Non ho molta esperienza ma una volta ho avuto questo problema. Ho controllato i miei percorsi di inclusione e li ho richiamati nell'ordine dei percorsi di libreria massimi utilizzati. e ho avuto un aumento del 30%. Penso che sia già noto da te, ma ho postato in qualsiasi modo ....... :)