Ottimizzazione dei siti Web basati su Kohana per velocità e scalabilità

Question

Un sito che ho creato con Kohana ieri è stato colpito da un'enorme quantità di traffico, costringendomi a fare un passo indietro e valutare parte del design.Sono curioso di sapere quali sono alcune tecniche standard per ottimizzare le applicazioni basate su Kohana?

Anche io sono interessato al benchmarking.Ho bisogno di configurare Benchmark::start() E Benchmark::stop() per ciascun metodo controller per visualizzare i tempi di esecuzione per tutte le pagine oppure sono in grado di applicare il benchmarking a livello globale e rapidamente?

Utilizzerò maggiormente la libreria Cache in futuro, ma sono aperto a ulteriori suggerimenti poiché sono sicuro che ci sono molte cose che posso fare di cui semplicemente non sono a conoscenza al momento.

Answer 1

Ciò che dirò in questa risposta non è specifico di Kohana e probabilmente può applicarsi a molti progetti PHP.

Ecco alcuni punti che mi vengono in mente quando parlo di prestazioni, scalabilità, PHP, ...
Ho utilizzato molte di queste idee mentre lavoravo su diversi progetti – e mi hanno aiutato;quindi probabilmente potrebbero aiutare anche qui.

Innanzitutto, quando si tratta di spettacoli, ci sono molti aspetti/domande da considerare:

• configurazione del server (sia Apache, PHP, MySQL, altri possibili demoni e sistema);potresti ricevere ulteriore aiuto a riguardo ServerFault, Credo,
• codice PHP,
• Interrogazioni del database,
• Utilizzi o meno il tuo server web?
• È possibile utilizzare qualsiasi tipo di meccanismo di memorizzazione nella cache?Oppure hai bisogno di dati sempre più aggiornati sul sito?

Utilizzando un proxy inverso

La prima cosa che potrebbe essere veramente utile è usare a procura inversa, Piace vernice, davanti al tuo server web:lasciarlo - Lascialo memorizzare nella cache quante più cose possibili, quindi solo le richieste che necessitano realmente di calcoli PHP/MySQL (e, ovviamente, alcune altre richieste, quando non sono nella cache del proxy) arrivare ad Apache/PHP/MySQL.

• Prima di tutto, il tuo CSS/Javascript/Images -- beh, tutto ciò che è statico -- probabilmente non è necessario essere sempre serviti da Apache
  • Quindi, puoi avere il proxy inverso nella cache di tutti questi.
  • Servire questi file statici non è un grosso problema per Apache, ma meno deve lavorare per quelli, più sarà in grado di fare con PHP.
  • Ricordare:Apache può servire solo un numero finito e limitato di richieste alla volta.
• Quindi, fai in modo che il proxy inverso serva quante più pagine PHP possibile dalla cache:probabilmente ci sono alcune pagine che non cambiano così spesso, e potrebbe essere servito dalla cache.Invece di utilizzare una cache basata su PHP, perché non lasciare che un altro server, più leggero, li serva (e recuperarli di tanto in tanto dal server PHP, in modo che siano sempre quasi aggiornati)?
  • Ad esempio, se disponi di alcuni feed RSS (Generalmente tendiamo a dimenticarli, quando cerchiamo di ottimizzare le prestazioni) che vengono richiesti molto spesso, averli in cache per un paio di minuti potrebbe far risparmiare centinaia/migliaia di richieste ad Apache+PHP+MySQL!
  • Lo stesso per le pagine più visitate del tuo sito, se non cambiano per almeno un paio di minuti (esempio:home page?), quindi, non c'è bisogno di sprecare CPU rigenerandoli ogni volta che un utente li richiede.
• Forse c'è una differenza tra le pagine servite per gli utenti anonimi (la stessa pagina per tutti gli utenti anonimi) e pagine servite per utenti identificati ("Salve signor X, ha nuovi messaggi", per esempio)?
  • In tal caso, probabilmente puoi configurare il proxy inverso per memorizzare nella cache la pagina fornita agli utenti anonimi (basato su un cookie, come in genere il cookie di sessione)
  • Significherà che Apache+PHP avrà meno da gestire:solo utenti identificati, che potrebbero rappresentare solo una piccola parte dei tuoi utenti.

Di utilizzando un proxy inverso come cache, per un'applicazione PHP puoi, ad esempio, dare un'occhiata a I risultati del benchmark mostrano un aumento del 400%-700% nelle capacità del server con APC e Squid Cache.
(Sì, stanno usando Squid e stavo parlando di Paint: è solo un'altra possibilità ^^ Varnish è più recente, ma più dedicato alla memorizzazione nella cache)

Se lo fai abbastanza bene e riesci a smettere di rigenerare troppe pagine ancora e ancora, forse non dovrai nemmeno ottimizzare il tuo codice ;-)
Almeno, forse non per fretta...Ed è sempre meglio eseguire le ottimizzazioni quando non si è troppo sotto pressione...

Come nota a margine:stai dicendo nell'OP:

Un sito che ho costruito con Kohana è stato sbattuto con un'enorme quantità di traffico ieri,

Questo è il tipo di situazione improvvisa in cui un proxy inverso può letteralmente salvare la situazione, se il tuo sito web può sopportare di non essere aggiornato entro il secondo:

• installalo, configuralo, lascialo sempre -- ogni giorno normale -- correre:
  • Configuralo per non mantenere le pagine PHP nella cache;o solo per una breve durata;in questo modo avrai sempre visualizzati i dati aggiornati
• E il giorno in cui prendi un effetto slashdot o digg:
  • Configura il proxy inverso per mantenere le pagine PHP nella cache;o per un periodo di tempo più lungo;forse le tue pagine non saranno aggiornate entro un secondo, ma ciò consentirà al tuo sito web di sopravvivere all'effetto digg!

A tale proposito, Come posso rilevare e sopravvivere all'essere "Slashdotted"? potrebbe essere una lettura interessante.

Per quanto riguarda PHP:

Prima di tutto:stai usando a versione recente di PHP?Ci sono regolarmente miglioramenti nella velocità, con nuove versioni ;-)
Ad esempio, dai un'occhiata a Benchmark dei rami PHP da 3.0 a 5.3-CVS.

Tieni presente che le prestazioni sono un buon motivo per utilizzare PHP 5.3 (Ho fatto alcuni benchmark (in francese), e i risultati sono ottimi)...
Un'altra buona ragione è, ovviamente, che PHP 5.2 ha raggiunto la fine del suo ciclo di vita e non viene più mantenuto!

Stai utilizzando qualche cache del codice operativo?

• sto pensando a APC - Cache PHP alternativa, ad esempio (pecl, Manuale), che è la soluzione che ho visto utilizzata di più e che viene utilizzata su tutti i server su cui ho lavorato.
  • Guarda anche: Diapositive APC Facebook,
  • O I risultati del benchmark mostrano un aumento del 400%-700% nelle capacità del server con APC e Squid Cache.
• In alcuni casi può davvero ridurre molto il carico della CPU di un server (Ho visto il carico della CPU su alcuni server passare dall'80% al 40%, semplicemente installando APC e attivando la sua funzionalità opcode-cache!)
• Fondamentalmente, l'esecuzione di uno script PHP avviene in due passaggi:
  • Compilazione del codice sorgente PHP in codici operativi (una specie di equivalente del bytecode di JAVA)
  • Esecuzione di tali codici operativi
  • APC li mantiene in memoria, quindi c'è meno lavoro da fare ogni volta che viene eseguito uno script/file PHP:recupera solo i codici operativi dalla RAM ed eseguili.
• Potrebbe essere necessario dare un'occhiata dell'APC opzioni di configurazione, A proposito
  • ce ne sono parecchi e alcuni possono avere un grande impatto sia sulla velocità/carico della CPU/facilità d'uso per te
  • Ad esempio, disabilitare [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat) può essere utile per il carico del sistema;ma significa che le modifiche apportate ai file PHP non verranno prese in considerazione a meno che non si svuoti l'intera cache del codice operativo;a riguardo, per maggiori dettagli, vedere ad es Per stat() o non per stat()?

Utilizzo della cache per i dati

Per quanto possibile, è meglio farlo evitare di fare sempre la stessa cosa.

La cosa principale a cui sto pensando sono, ovviamente, le query SQL:molte delle tue pagine probabilmente eseguono le stesse query e i risultati di alcune di queste probabilmente sono quasi sempre gli stessi...Il che significa moltissimo "inutile" query effettuate al database, che deve dedicare tempo a servire gli stessi dati più e più volte.
Naturalmente, questo vale anche per altre cose, come le chiamate ai servizi Web, il recupero di informazioni da altri siti Web, calcoli pesanti, ...

Potrebbe essere molto interessante per te individuare:

• Quali query vengono eseguite molte volte, restituendo sempre gli stessi dati
• Quale altro (pesante) i calcoli vengono eseguiti molto tempo, restituendo sempre lo stesso risultato

E memorizza questi dati/risultati in una sorta di cache, in modo che siano più facili da ottenere -- Più veloce - e non devi andare al tuo server SQL per "niente".

Ottimi meccanismi di memorizzazione nella cache sono, ad esempio:

• APC:oltre all'opcode-cache di cui ho parlato prima, permette di archiviare i dati in memoria,
• E/o memcached (Guarda anche), che è molto utile se lo hai letteralmente molti di dati e/o sono utilizzando più server, così come è distribuito.
• ovviamente puoi pensare ai file;e probabilmente molte altre idee.

Sono abbastanza sicuro che il tuo framework sia dotato di alcune cose relative alla cache;probabilmente lo sai già, come hai detto "Utilizzerò maggiormente la libreria Cache in futuro" nell'OP ;-)

Profilazione

Ora, una cosa carina da fare sarebbe usare il file Xdebug estensione a profilare la tua candidatura:spesso permette di trovare un paio di punti deboli abbastanza facilmente - almeno, se c'è qualche funzione che richiede molto tempo.

Configurato correttamente, genererà file di profilazione che potranno essere analizzati con alcuni strumenti grafici, come:

• KCachegrind:il mio preferito, ma funziona solo su Linux/KDE
• Wincachegrind per finestre;sfortunatamente fa un po' meno cose di KCacheGrind: in genere non visualizza i callgraph.
• Webgrind che gira su un server web PHP, quindi funziona ovunque, ma probabilmente ha meno funzionalità.

Ad esempio, ecco un paio di screenshot di KCacheGrind:

<sub>(fonte: pascal-martin.fr)

(fonte: pascal-martin.fr)</sub>

(A proposito, il callgraph presentato nel secondo screenshot è in genere qualcosa che né WinCacheGrind né Webgrind possono fare, se ricordo bene ^^)

(Grazie @Mikushi per il commento) Un'altra possibilità che non ho utilizzato molto è the xhprof estensione:aiuta anche con la profilazione, può generare callgraph, ma è più leggero di Xdebug, il che significa che dovresti essere in grado di installarlo su un server di produzione.

Dovresti essere in grado di usarlo da solo XHGui, che aiuterà per la visualizzazione dei dati.

Dal punto di vista SQL:

Ora che abbiamo parlato un po' di PHP, notiamo che lo è è più che possibile che il collo di bottiglia non sia il lato PHP delle cose, ma quello del database...

Almeno due o tre cose, ecco:

• Dovresti determinare:
  • Quali sono le query più frequenti eseguite dalla tua applicazione
  • Se questi sono ottimizzati (usando il indici a destra, principalmente?), usando il EXPLAIN istruzione, se si utilizza MySQL
    • Guarda anche: Ottimizzazione di SELECT e altre istruzioni
    • Puoi, ad esempio, attivare log_slow_queries per ottenere un elenco delle richieste che richiedono "troppo" tempo e inizia la tua ottimizzazione da quelli.
  • se potresti memorizzare nella cache alcune di queste query (vedi cosa ho detto prima)
• Il tuo MySQL è ben configurato?Non ne so molto, ma ci sono alcune opzioni di configurazione che potrebbero avere un certo impatto.
  • Ottimizzazione del server MySQL potrebbe darti qualche informazione interessante a riguardo.

Tuttavia, le due cose più importanti sono:

• Non andare al DB se non è necessario: cache quanto più possibile!
• Quando devi andare al DB, usa query efficienti:utilizzare gli indici;e profilo!

E adesso?

Se stai ancora leggendo, cos’altro potrebbe essere ottimizzato?

Beh, c'è ancora spazio per miglioramenti...Un paio di idee orientate all’architettura potrebbero essere:

• Passa a un'architettura a più livelli:
  • Metti MySQL su un altro server (2 livelli:uno per PHP;l'altro per MySQL)
  • Utilizza diversi server PHP (e bilanciare il carico degli utenti tra questi)
  • Utilizza altre macchine per file statici, con un server web più leggero, come:
    • lighttpd
    • O nginx -- questo sta diventando sempre più popolare, comunque.
  • Utilizza diversi server per MySQL, diversi server per PHP e diversi proxy inversi davanti a questi
  • Ovviamente:installare memcached demoni su qualunque server abbia una certa quantità di RAM libera e usali per memorizzare nella cache quanto più possibile / ha senso.
• Utilizzare qualcosa di "più efficiente" di Apache?
  • Ne sento parlare sempre più spesso nginx, che dovrebbe essere eccezionale quando si tratta di PHP e di siti Web ad alto volume;Non l'ho mai usato personalmente, ma potresti trovare alcuni articoli interessanti a riguardo in rete;
    • ad esempio, Prestazioni PHP III: esecuzione di nginx.
    • Guarda anche: PHP-FPM - Gestore processi FastCGI, che è fornito in bundle con PHP >= 5.3.3 e fa miracoli con nginx.

Beh, forse alcune di queste idee sono un po' eccessive nella tua situazione ^^
Ma, ancora...Perché non studiarli un po', per ogni evenienza?;-)

E che dire di Kohana?

La tua domanda iniziale riguardava l'ottimizzazione di un'applicazione che utilizza Kohana...Beh, ne ho postati alcuni idee che sono vere per qualsiasi applicazione PHP...Ciò significa che sono vere anche per Kohana ;-)
(Anche se non specifico ^^)

Ho detto:utilizzare la cache;Kohana sembra supportarne alcuni roba di memorizzazione nella cache (Ne hai parlato tu stesso, quindi niente di nuovo qui...)
Se c'è qualcosa che può essere fatto velocemente, provalo ;-)

Ho anche detto che non dovresti fare nulla che non sia necessario;c'è qualcosa abilitato di default in Kohana che non ti serve?
Navigando in rete, sembra che ci sia almeno qualcosa riguardo al filtraggio XSS;ne hai bisogno?

Comunque ecco un paio di link che potrebbero esserti utili:

• Discussione generale su Kohana:Memorizzazione nella cache?
• Supporto comunitario:Ottimizzazione del sito web:Massime prestazioni del sito web utilizzando Kohana

Conclusione?

E, per concludere, un semplice pensiero:

• Quanto costerà alla tua azienda pagarti 5 giorni? - considerando che è un periodo di tempo ragionevole per apportare alcune ottime ottimizzazioni
• Quanto costerà l'acquisto alla tua azienda (pagare per?) un secondo server e la sua manutenzione?
• E se dovessi ingrandirlo?
  • Quanto costerà trascorrere 10 giorni?Di più?ottimizzare ogni possibile parte della tua applicazione?
  • E quanto per un paio di server in più?

Non sto dicendo che non dovresti ottimizzare:dovresti assolutamente!
Ma scegli ottimizzazioni "rapide" che ti daranno grandi ricompense Primo:l'utilizzo di una cache del codice operativo potrebbe aiutarti a ottenere tra il 10 e il 50% di riduzione del carico della CPU del tuo server...E ci vogliono solo un paio di minuti per la configurazione ;-) D'altra parte, spendere 3 giorni per il 2%...

Oh, e comunque:prima di fare qualsiasi cosa: mettere in atto alcune cose di monitoraggio, così saprai quali miglioramenti sono stati apportati e come!
Senza monitoraggio, non avrai idea degli effetti di ciò che hai fatto...Nemmeno se si tratta di una vera ottimizzazione oppure no!

Ad esempio, potresti usare qualcosa del genere RRDtool + cactus.
E mostrare al tuo capo una bella grafica con un calo del carico della CPU del 40% è sempre fantastico ;-)

Comunque, e per concludere davvero: divertiti!
(Sì, ottimizzare è divertente!)
(Ergh, non pensavo che avrei scritto così tanto...Spero che almeno alcune parti di questo siano utili...E dovrei ricordare questa risposta:potrebbe essere utile altre volte...)

Answer 2

XDebug e WinCacheGrind o WebCacheGrind al profilo e analizzare esecuzione di codice lento.

_{(fonte: jokke.dk )}

Answer 3

Codice profilo con XDebug .

Con un sacco di caching. Se le pagine sono relativamente statiche, poi invertire proxy potrebbe essere il modo migliore per farlo.

Answer 4

Kohana è fuori dalla scatola molto molto veloce, tranne che per l'uso di oggetti di database. Per citare Zombor "È possibile ridurre l'utilizzo della memoria, assicurando che si sta utilizzando l'oggetto risultato database invece di array risultato". Questo fa una differenza di prestazioni HUGEE su un sito che viene sbattuto. Non solo utilizzare più memoria, rallenta l'esecuzione di script.

Inoltre - è necessario utilizzare la cache. Io preferisco memcache e usarlo nei miei modelli in questo modo:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

Questo aumenterà anche notevolmente le prestazioni. Queste due tecniche migliorate prestazioni siti dell'80%.

Se ti ha dato qualche informazione in più su dove si pensa che il collo di bottiglia è, io sono sicuro che potremmo dare alcune idee migliori.

Verificate anche YSlow (google) per alcuni altri suggerimenti di prestazioni.

Answer 5

strettamente correlate alle Kohana (probabilmente avete già fatto, o no):

In modalità di produzione:

1. Abilita cache interna (questo sarà memorizzare nella cache solo il Kohana :: risultati find_file, ma questo in realtà può aiutare molto.
2. Disabilita profiler

Solo i miei 2 centesimi:)

Answer 6

Sono assolutamente d'accordo con la XDebug e le risposte di caching. Non guardare nello strato Kohana per l'ottimizzazione fino a quando hai identificato la velocità e la scala più grandi colli di bottiglia.

XDebug vi dirà che eri si spende la maggior parte del vostro tempo e identificare 'punti caldi' nel codice. Mantenere queste informazioni profilazione in modo da poter basale e misurare miglioramenti delle prestazioni.

Esempio problema e la soluzione: Se si scopre che si sta costruendo oggetti costosi dal database ogni volta, che in realtà non cambiano spesso, allora si può guardare a loro cache con meccanismo di memcached o un altro. Tutte queste correzioni prestazioni richiedono tempo e di aggiungere complessità al sistema, in modo da essere sicuri della vostra ostacoli prima di iniziare a risolverli.