Quale server MySQL offre prestazioni migliori per Magento


30

Cosa usi come server MySQL per Magento?

  • MySQL (Oracle)
  • Percona
  • altri (MariaDB)

Percona offre una serie di miglioramenti per l'archiviazione InnoDB utilizzata da Magento in modo intensivo, ma questi miglioramenti fanno la differenza quando si esegue un negozio Magento.

Come migliorare le prestazioni (approcci generali sull'architettura, non informazioni specifiche sull'impostazione di variabili specifiche come innodb_flush_log_at_trx_commit=2e così via). So che NBS ha provato la replica master-master ma non è stabile.

Ho riscontrato alcuni problemi con una replica master-slave con letture reindirizzate verso lo slave, perché c'erano alcuni ritardi nella replica dei dati.

Uscire da MySQL il più possibile? (cerca in solr e così via).


1
FlorinelChis, Grazie per la domanda, ma questo è un argomento molto ampio (miglioramenti delle prestazioni) e la selezione di un motore di database è un campo a sé stante. A meno che non ci sia una forte componente di questa domanda relativa in modo specifico a Magento, questo potrebbe essere meglio posto nelle nostre domande e risposte DBA . Ma ovunque poni la tua domanda, dovrai fornire molte più informazioni sui problemi specifici che stai riscontrando. Scusa per la confusione e buona fortuna!
Robert Cartaino

Capisco che la domanda è ambigua e sembra un argomento molto ampio. Per quanto riguarda Magento non è così ampio, è legato a dettagli molto specifici. MySQL è il collo di bottiglia quando è necessario ridimensionare Magento e dalla mia esperienza, passare a Percona in alcune configurazioni aumenta le prestazioni. Voglio sapere come fanno gli altri amministratori di sistema Magento. Non stavo cercando informazioni molto specifiche come è necessario impostare innodb-flush-log-at-trx-commit = 2, ma piuttosto verso un approccio sull'uso di Mysql, percona o altri (MariaDB) per ottenere prestazioni migliori.
FlorinelChis,

FlorinelChris, non sono un esperto di dominio, ma in base al voto e alle bandiere, sospetto che questa domanda abbia bisogno / meriti ulteriori informazioni per ottenere una risposta utile. Ma sono felice di riaprirlo per consentire alla comunità di gestirlo in modo appropriato. Potresti voler vedere quali informazioni puoi aggiungere in modo che la gente non rimanga indovinando il modo migliore per aiutarti.
Robert Cartaino

Risposte:


73

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:

  1. Tempo di caricamento della pagina percepito dall'utente singolo
  2. 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.

  1. Non è stata eseguita alcuna regolazione lato negozio come nell'esempio 1
  2. 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
Pacchetti firewall

Varnish Traffic
Varnish Traffic

Traffico Nginx
Traffico Nginx

Caricamento MySQL
Discussioni MySQL Byte MySQL Domande MySQL

Carico CPU
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.

Distribuzione del carico

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 .


è una risposta lunga :) Molto apprezzato, grazie. Per quanto riguarda la scala e il carico su MySQL, ecco il grafico di MySQL: twitter.com/ze_m0n5t3r/status/232864932482396160 . L'ottimizzazione di Magento è un processo costante (vari bug, codice non ottimizzato, ecc.). La riduzione del carico (spostamento di ricerca / navigazione su solr, migliore memorizzazione nella cache) è il primo approccio. Inoltre, il DB deve comportarsi meglio con una cache fredda. E quando ciò accade, sto cercando un sito web più lento con una capacità maggiore.
FlorinelChis,

Prego. Non c'è motivo di dire che non si può avere un sito Web veloce e una grande capacità - lo fanno i nostri clienti . Ovviamente c'è un po 'di più nelle prestazioni di MySQL di quanto abbia scelto di menzionare sopra. Ma ciò darebbe in qualche modo la nostra "salsa segreta". Ho orientato questa risposta verso i proprietari di piccoli negozi (<25k pezzi unici / giorno) come guida "iniziale" verso MySQL.
Ben Lessani - Sonassi,

Proprio come un sidenote. Guardando il grafico, gli inserti hanno raggiunto il picco di circa 10 volte il carico normale, gli aggiornamenti sono rimasti bassi e le selezioni hanno mostrato il carico maggiore. Farei un gioco d'azzardo: gli inserti erano il registro dei clienti, la ricerca di pertinenza / domande, o dio vietare, sessioni. Ma comunque un numero abbastanza piccolo da non costituire un problema o addirittura considerare Master / Master. Quindi, in base al tuo grafico, la semplice aggiunta di più hardware sarebbe più che adeguata; con uno o più schiavi che lo seguono. E mantenere la cache calda tra i riavvii è facile con Percona, s.onas.si/5g8s
Ben Lessani - Sonassi,

la ricerca era solr, sessioni - memcache. Conosci qualcuno che gestisce un master-master di successo? (NBS ha fallito in questo, anche in questo abbiamo fallito, è instabile con Magento, funziona bene su altre app php più leggere)
FlorinelChis

1
Questa è una risposta incredibile. Volevo solo dirlo.
Dustbuster
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.