Stai entrando in un vasto, ampio mondo di ottimizzazione qui e sicuramente non esiste un approccio unico per tutti.
Definire le prestazioni
Intendi il tempo di caricamento della pagina per un singolo utente o la capacità complessiva / concorrenza totale? I due sono molto diversi e non strettamente correlati. È del tutto possibile avere un negozio veloce con capacità limitata; o un negozio lento con molta capacità.
Quindi, quando si affrontano entrambi i tipi di prestazioni:
- Tempo di caricamento della pagina percepito dall'utente singolo
- Capacità / concorrenza totale
Devi affrontare ciascuno in modo indipendente con le proprie soluzioni, soprattutto perché ognuno ha i propri colli di bottiglia.
Supponiamo che tu sia con un host competente che ha già configurato in modo ottimale gli altri aspetti del tuo server per il tuo negozio.
Tempo di caricamento della pagina percepito dall'utente singolo
MySQL è il collo di bottiglia
. Non direttamente. Riguarda la latenza, nella maggior parte dei casi durante il test del tempo di caricamento della pagina: verranno colpite solo le cache. Quindi la chiave qui è minimizzare la latenza.
- Ottimizza le dimensioni della cache di MySQL in modo appropriato (non esiste una risposta corretta, ottimizziamo le impostazioni in modo completamente diverso, mensile, per negozio)
- Ridurre la latenza della rete. Per frame a 64 byte; 51,2µs per 10 Mbps, 5,12µs per 100 Mbps e 4,096µs per 1Gbps. Ciò offre un miglioramento del 20% solo passando da 100 Mbps a 1 Gbps. s1
- Aumentare la capacità della rete. Saresti sorpreso dal fatto che molti megabyte al secondo vengano scambiati tra un server Web e DB, in genere superiore a 10 MB / s, quindi è richiesto un minimo di 100 Mb / s s1 . Oppure spostare semplicemente il server DB localmente.
- Utilizzando SOLR. I motori esterni a volte sono più adatti, SOLR è certamente più veloce per i cataloghi GRANDI (e sottolineerei, cataloghi più grandi ). Anche il SOLR non sintonizzato produrrà una navigazione a più livelli e risultati di ricerca più veloci di MySQL.
Ma questi cambiamenti avranno un impatto così frazionario sul tempo di caricamento della pagina - dove il collo di bottiglia è davvero altrove.
- Ottimizza l'applicazione. Magento ha alcuni bug abbastanza grandi nel modo in cui costruisce le raccolte e le memorizza nella cache; ci siamo imbattuti in una serie di grandi problemi di codice di base che possono compromettere le prestazioni. In alcuni casi, semplicemente rimuovendo la visualizzazione del conteggio dei prodotti dai risultati di navigazione a più livelli, sono stati rasati 2 secondi di caricamento di una grande raccolta.
- Esamina i log lenti di MySQL. Controlla le query lente e aggiungi gli indici se necessario. La differenza tra l'esecuzione di una query complessa con più join con e senza indici appropriati può essere di decine di secondi .
L'applicazione è il collo di bottiglia. Non il software. Quindi semplicemente migliorare il core-code o rendere il tuo modello meno pesante avrà un effetto molto più drammatico sulle prestazioni rispetto a QUALSIASI cambiamento di configurazione di MySQL.
Con cosa non dovremmo preoccuparci
- Modifica del motore di archiviazione. MariaDB e Percona condividono lo stesso motore InnoDB - Percona XtraDB. Possono essere trattati come una cosa sola. In termini di tempo di esecuzione di una singola query, le prestazioni rispecchieranno esattamente una build MySQL vaniglia. Questo entra in gioco sotto carico / concorrenza.
- Esecuzione di uno slave MySQL. Ciò non migliorerà le prestazioni se lo slave non si trova fisicamente più vicino (dal punto di vista della rete) o se lo slave ha un hardware migliore rispetto al master. Questo entra in gioco sotto carico / concorrenza.
- Esecuzione di un server DB esterno. Questo è di gran lunga il peggior consiglio che vediamo ripetutamente distribuito da molti host / agenzie. Fino a quando non hai raggiunto un limite massimo di hardware / risorse o hai più server Web (leggi: alta disponibilità), MySQL sul computer locale per un negozio Magento è una buona idea. Elimina tutto l'overhead e la latenza della rete. Anche una rete da 100 Gb / s (sì, cento gigabit al secondo) non si confronta con un socket unix locale per volume, throughput e latenza non elaborati.
s1 Solo per server database separati. Non si applica ai server DB locali.
Capacità / concorrenza totale
MySQL è
forse il collo di bottiglia . Ma solo una volta che hai inchiodato le tue prestazioni e capacità di PHP al punto in cui MySQL sta rallentando le cose. Se hai Varnish e FPC correttamente configurati (non farci iniziare su quanti tentativi falliti abbiamo visto con nessuno dei due) - allora MySQL diventa un collo di bottiglia.
Quindi oltre alle modifiche sopra.
- Cambia motore MySQL. XtraDB può eccellere sotto carico e mostra reali vantaggi rispetto a una distribuzione MySQL di serie.
- Rimani aggiornato con MySQL. 5.5 funziona meglio di 5.0 sotto carico.
- Cambia driver MySQL PHP. PHP 5.3 e versioni successive hanno un driver MySQL nativo, ma in alcune circostanze, abbiamo trovato PHP 5.2 con il driver separato per superare MySQLND per Magento. Provalo tu stesso
- Cambia motore di ricerca. Spostare la ricerca su SOLR / Sphinx (o anche su alcuni servizi esterni di terze parti) può davvero alleviare l'onere del carico non transazionale (es. Persone che non effettuano ordini)
- Cambia il motore di navigazione a più livelli. Ancora una volta, SOLR è un motore geniale per la navigazione a più livelli e grazie alla sua natura non bloccante è molto più veloce di MySQL.
- Aggiungi uno slave MySQL. Questo fa aiuto browsing carico (non transazionale), ma non vi aiuterà a elaborare più ordini per ora - come si fa affidamento sul master di processo e replicare questi dati
Con cosa non dovremmo preoccuparci
- Maestro / Maestro. A causa del punto di non ritorno piuttosto elevato della saturazione hardware di una configurazione Master / Slave (superiore a 1000 ordini l'ora), non abbiamo mai trovato un requisito per utilizzare Master / Master in produzione. Abbiamo eseguito test approfonditi, ma non l'abbiamo mai trovato vantaggioso dal punto di vista delle prestazioni e con i rischi e i problemi intrinseci di Master / Master, semplicemente non ne vale la pena.
Scalabilità di lettura e scrittura
L'ultimo paragrafo porta davvero ad un'area chiave della scalabilità in lettura e scrittura. Il ridimensionamento in lettura può essere eseguito all'infinito senza troppe complicazioni con l'aggiunta di sempre più slave.
Dato che il rapporto Magento tra letture e scritture è di circa lo 0,1%, la considerazione delle scritture non dovrebbe essere motivo di preoccupazione. Ecco perché non mi sono preoccupato di menzionare MySQL Cluster e le sue funzioni intelligenti come l'auto-sharding (suddividere le tabelle in macchine separate).
Hardware, hardware, hardware
L'hardware è facilmente la risposta più rapida quando si tratta di miglioramento, quindi non ho deliberatamente menzionato sopra in entrambi gli scenari.
Ma tutte le modifiche al software nel mondo non faranno alcuna differenza se l'hardware sottostante non è sufficiente. Ciò potrebbe significare ...
- Switch di bassa qualità con buffer limitati
- Collegamenti di rete eccessivamente saturi
- Server geograficamente distanti
- Rete scadente QoS / CoS
- Quantità totale limitata di RAM
- RAM a bassa larghezza di banda di memoria
- Sottosistema HDD a IOP bassi
- Controller RAID software
- CPU a bassa velocità di clock
- Chipset a bassa larghezza di banda
- Virtualizzazione hardware (quasi tutti i tipi tranne la virtualizzazione a livello di kernel)
Al giorno d'oggi, c'è un limite molto alto su quanto in alto puoi effettivamente scalare sull'hardware. Ignoriamo il mito dell'infinito ridimensionamento "nel cloud" poiché l'hardware del cloud tende ad essere abbastanza mediocre. Ad esempio, i modelli di punta di Amazon sono solo 12 core a 3,3 GHz. Ma al di fuori di questo, ci sono alcuni server molto potenti disponibili: il nostro server principale ha 160 core e 2 TB (sì, Terabyte) di RAM. Non abbiamo ancora visto nessuno superare le capacità di questo.
Quindi hai un campo di applicazione enorme per il ridimensionamento verticale, prima ancora di dover considerare il ridimensionamento orizzontale.
Il bersaglio sempre in movimento
Vale la pena ricordare che nel perseguimento delle prestazioni, il collo di bottiglia continuerà sempre a muoversi.
Per un negozio Magento di serie.
Attiva le cache. PHP è il collo di bottiglia
Aggiungi una cache back-end. PHP è il collo di bottiglia
Aggiungi una cache di pagina intera a livello di applicazione. PHP è il collo di bottiglia
Aggiungi una cache front-end a livello di server (es. Varnish). MySQL è il collo di bottiglia
Aggiungi una ricerca alternativa / motore di navigazione a più livelli (ad esempio SOLR / Sphinx). PHP è il collo di bottiglia
Aggiungi altri server applicazioni. MySQL è il collo di bottiglia
Aggiungi uno slave MySQL. La cache front-end è il collo di bottiglia
Aggiungi altri server cache front-end. PHP è il collo di bottiglia
Aggiungi altri server applicazioni. SOLR / Sphinx è il collo di bottiglia
Eccetera.
Praticamente diventa un caso di ripetizione del risciacquo. Ma ciò che è chiaro da capire è che MySQL non è certamente il primo punto di riferimento per l'ottimizzazione - ed entra in gioco solo quando MySQL sta consumando più CPU in proporzione a PHP - e questo accade SOLO quando FPC e Varnish sono in uso e i server stanno puramente elaborando gli ordini e nient'altro (perché tutto il resto è nella cache).
Non apportare modifiche alla cieca
Semplicemente aggiungendo uno slave MySQL perché ci leggi sopra, che ti aiuterà, può costare prestazioni e affidabilità a un livello enorme. Una rete congestionata, un server slave con specifiche ridotte o persino impostazioni errate possono causare problemi di replica che possono rendere il tuo negozio più lento di quanto non fosse inizialmente o causare problemi di sincronizzazione tra Master e Slave.
Per mettere le cose in prospettiva - alcuni esempi del mondo reale.
Esempio 1 - 300 ordini all'ora
Abbiamo utilizzato il seguente hardware per servire 300 ordini all'ora ; e solo a quel punto di non ritorno, abbiamo sentito la necessità di aggiungere un server MySQL dedicato e uno slave MySQL locale.
1
CPU del server : 2x Intel E5-4620
RAM: 64 GB HDD: 4x SSD IOP / s 80k
RAID: Hardware RAID 10
Magento Versione: Magento EE
OS: MageStack
Durante tutto il tempo, le medie di carico sono rimaste inferiori a 3,00.
Esempio 2 - 180 ordini all'ora
Solo due giorni fa, un nostro nuovo cliente ha facilmente assorbito un forte picco di traffico. Elaborazione di 180 ordini all'ora con un server singolo e Magento Community Edition .
1
CPU server : 2x Intel E5-4620
RAM: 64 GB HDD: 4x SSD IOP / s 80k
RAID: Hardware RAID 10
Magento Versione: Magento CE Sistema
operativo: MageStack
Sito Web: Wellgosh.com
Durante tutto il tempo, le medie di carico sono rimaste inferiori alle 6,00. Il carico era maggiore in questo scenario e ciò dipendeva da un paio di fattori.
- Non è stata eseguita alcuna regolazione lato negozio come nell'esempio 1
- La mancanza di un FPC a livello di applicazione
E data la recency di questo, abbiamo ancora le statistiche dettagliate per dare un feedback per mezzo di grafici. Questi raccontano una storia eccellente di come il carico è distribuito tra i componenti chiave di un'architettura Magento separata (bilanciamento del carico, web server, server db ecc. - usando MageStack ).
Quindi da davanti a dietro ... la data che vuoi vedere è alle 12:00 del 22 febbraio.
Pacchetti firewall
Varnish Traffic
Traffico Nginx
Caricamento MySQL
Carico CPU
E, soprattutto, la distribuzione del carico
Questa immagine racconta davvero tutto. Ed è che MySQL non è certamente un peso - non ancora almeno. Quindi il nostro consiglio, focalizza le tue preoccupazioni prestazionali altrove, a meno che tu non stia elaborando più di qualche migliaio di ordini l'ora.
E in sintesi
Apportare modifiche alle prestazioni non è "taglia unica". Si tratta di analizzare i colli di bottiglia attuali e apportare sottili modifiche / adeguamenti per adattarsi al tuo negozio e alla tua infrastruttura.
Ma a parte le prestazioni, ci sono altri vantaggi nell'uso di Percona
Usiamo Percona XtraDB, quasi esclusivamente. Eseguiamo build compilate su misura di MySQL che abbiamo sviluppato appositamente per Magento e che aveva consultato Percona durante il processo. Ma non è stata solo la performance a influenzare questa scelta.
- Il Percona Toolkit
- pt-query-digerire
- xtrabackup
- eccetera.
- Frequenza di rilascio Percona
- Supporto consultivo Percona
- La cache calda si riavvia con la conservazione del pool InnoDB
E altro ancora. Quindi usarlo su MySQL ha altri vantaggi oltre alle prestazioni. In effetti, MySQL è ed è sempre stata l'ultima delle nostre preoccupazioni nella ricerca di prestazioni e stabilità.
Attribuzioni: wellgosh.com , sonassi.com , iebmedia.com .