Attualmente stiamo lavorando con un requisito secondo cui la prima risposta dal server Web deve arrivare a meno di 200 ms nel Regno Unito. Attualmente sotto 2 server Web dedicati con bilanciamento del carico e 1 server db, arriviamo a 800 ms.

Il sito al momento ha meno di 5 clienti, 2 prodotti, 4 categorie, non c'è frontend al sito al momento, è senza stile e senza immagini.

Viene anche eseguito su nginx con Varnish.

Qualcuno può darmi qualche consiglio sulle impostazioni del web server? Perché la nostra arriva lentamente? Cosa puoi consigliare per ottimizzare questo? Devi ottenere il 400% più veloce!

Mi mordo.

Quella prima risposta dal web server deve arrivare a meno di 200 ms nel Regno Unito
Al momento non c'è frontend al sito, è privo di stile e di immagini.

Non otterrai queste cifre senza l'aiuto di Vernice o FPC (o entrambi). Spero certamente che questa cifra non debba anche includere contenuto statico (ogni volta che decidi di aggiungerlo) - poiché è quasi impossibile da raggiungere (a corto di avere poco o niente immagini / js / css).

Stiamo arrivando a 800ms
Viene anche eseguito su Nginx con Varnish

Varnish è configurato in modo errato.

Un'installazione correttamente configurata di Varnish fornirà tempi di caricamento della pagina <100 ms (vediamo più vicino a <10 ms).

In effetti, per Magento, dovresti aspettarti di vedere qualcosa del genere,

Quando un cliente non ha effettuato l'accesso ...
Cioè. Non aver creato una sessione unica (aggiungi al carrello / lista dei desideri, accesso ecc.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Quando un cliente ha effettuato l'accesso ...
Vale a dire. Dopo aver creato una sessione unica (accesso, articoli nel carrello ecc.). A questo punto la vernice sarà probabilmente fuori. E se hai scelto di usare ESI - a seconda delle chiamate inverse, può mantenere un tempo di caricamento della pagina simile a quello della cache FPC (a causa delle spese generali di bootstrap) - o effettivamente aumentare i tempi di caricamento della pagina oltre a essere staccato.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Non è un caso di messa a punto di Varnish - è un caso di - "in realtà non stai memorizzando nulla nella cache" .

I file di configurazione del server Magento ideale

Non ce n'è uno, beh, non del tutto.

Gestiamo oltre 400 server, tutti negozi puramente Magento - di dimensioni e capacità variabili. Ed è raro che i file di configurazione che abbiamo su uno corrispondano a quelli di un altro. Questo perché non tutte le aziende sono uguali.

I colli di bottiglia possono formarsi per diversi motivi:

1. Elevato numero di visitatori in concorrenza, con sessioni attive
2. Vittime di robot "cattivi" che generano carichi necessari e inestimabili
3. Alta percentuale di accessi a livelli di navigazione
4. Numero elevato di query di ricerca
5. Elevato volume di transazioni all'ora
6. Modello mal costruito
7. Troppe estensioni di terze parti / lente / ingombranti
8. Link in entrata obsoleti che portano a un'alta percentuale di 404 visite
9. Capacità dell'interfaccia di rete al limite
10. Catalogo grande / complesso (molti prodotti / categorie / attributi)

Quindi, con negozi in tutto questo spettro, ognuno ha un approccio diverso per prestazioni più ottimali.

Per risolvere i problemi descritti sopra; eviteremo deliberatamente di dichiarare "hardware migliore / migliore"

1. Usa un FPC oltre a quello di Varnish
2. Filtra / blocca i bot danneggiati ai margini della rete o reindirizza tutte le richieste a Varnish indipendentemente dallo stato / URL del cookie
3. Cambia la navigazione a livelli di magazzino in SOLR, rendi dipendenti i filtri di navigazione a livelli
4. Modifica la ricerca titoli in SOLR
5. Distribuisci il carico MySQL attraverso la configurazione Master / Slave - fallo solo quando il carico di navigazione è assorbito da Varnish / FPC
6. Ricostruisci il modello
7. Spogliali
8. Monitorare continuamente i log di accesso e riscrivere gli URL su Nginx / Varnish prima della consegna. Se lo fai a livello di Nginx, assicurati che Varnish memorizzi nella cache i reindirizzamenti 301/302.
9. Suddividere il contenuto statico in una rete CDN o migliorare la connettività
10. Aggiungi altro hardware (beh, dovevamo dirlo ad un certo punto)

Quindi, con questo in mente, vedrai che probabilmente non ci sarà un file di configurazione Nginx, un file di configurazione del pool fcgi PHP, un file di configurazione MySQL o un file di configurazione Varnish che saranno gli stessi. Abbinalo alle modifiche hardware stesso; memoria disponibile, prestazioni I / O (HDD e rete) e CPU - e scoprirai che ci sono sottili variazioni che portano al guadagno delle prestazioni del 400% che desideri - ma nessuna risposta rapida troverai prontamente online.

È possibile copiare + incollare il white paper Magento sponsorizzato Peer 1 sulla peformance (non lo consigliamo); spero che le impostazioni non superino la memoria disponibile, i limiti dei thread, gli stati TCP / IP, la capacità I / O e portino a prestazioni inferiori rispetto a una configurazione Apache / mod_php vanilla.

Quindi continuiamo.

Lo stack server Magento ideale

È più probabile che ti avvicini alla realtà. Un buon esempio per dimostrarlo è mostrare come è configurato un sistema operativo Magento dedicato, MageStack

Prendi i sottocomponenti separati e avrai un elenco dei software più ottimali / critici, se configurato correttamente , per eseguire un negozio Magento. In particolare:

Firewall, filtro DOS, Load Balancer, Varnish, Nginx, PHP, Redis, Memcached, MySQL

Quindi quando chiedi:

Qual è la migliore installazione di Magento Server?

Qual è esattamente il tuo obiettivo?

1. Alta disponibilità
2. Affidabilità
3. Semplicità di amministrazione
4. Prestazione
5. scalabilità

Basta lezione, come lo faremmo

Per rispecchiare parzialmente la risposta fornita in caso di errore del server in una direzione simile. Hai 3 server a tua disposizione, quindi prima orientali nel modo migliore. Eviteremo una soluzione altamente disponibile in quanto è molto al di là dell'ambito di questa risposta.

I sottocomponenti richiesti per una configurazione multi-server sono:

• Firewall
• Load Balancer
• Server web
• Server MySQL
• Archiviazione comune

Quindi polifunzioneremo alcuni dei sistemi. La conformità PCI-DSS determina un ruolo per ciascun server. Quindi, con 5 ruoli e 3 server, verrai immediatamente violato. MageStack aggira il problema utilizzando la virtualizzazione: potresti fare lo stesso.

Server 1: Load Balancer + Web server
Server 2: Web server
Server 3: Server database

Senza bassa latenza e significativa larghezza di banda di rete (> 1 Gbps, <125µs), anziché avere spazio di archiviazione comune, è meglio archiviare semplicemente la directory principale dello store su ogni macchina e replicare i dati, sia in tempo reale che ionotifyusando un cronlavoro. Ancora una volta, eviteremo i file system di rete come NFS o i dispositivi a blocchi replicati come Gluster o DRBD, poiché sono necessari un ampio tuning e una larghezza di banda di rete decente.

La vernice deve sedersi il più vicino possibile alla parte anteriore. Ma Varnish non può decrittografare SSL. Quindi combinalo con un terminatore SSL; Nginx, Pound, Stunnel, Stud ecc. Il bilanciamento del carico integrato in Varnish non è eccezionale, ma sarebbe adeguato per una configurazione a 2 server.

Nginx + PHP-FPM va bene, ma non bere troppo del kool-aiuti Nginx. Funzionerà in modo quasi identico a una configurazione tradizionale di Apache / mod_php, ecco alcune buone letture sul perché non usare Nginx . Nginx è buono, molto buono, ma certamente non è un collo di bottiglia di un negozio Magento - e data la sua complessità e la mancanza di supporto nativo Magento. La maggior parte degli amministratori di sistema inesperti trarrebbe vantaggio dall'uso di Apache / mod_php su qualsiasi altra cosa. Questo può sembrare una raccomandazione arcaica sull'uso di PHP-FPM - ma i nostri test sulle prestazioni hanno dimostrato che le prestazioni sono solo ~ 7% più veloci con la soluzione Nginx - se configurate correttamente. L'ottimizzazione e l'esperienza richieste per una configurazione Nginx / PHP-FPM affidabile e ad alte prestazioni sono abbastanza vaste per riuscire a superare le prestazioni di Apache / mod_php. Qualunque cosa tu scelga di usare, è la tua chiamata.

Il server di database è semplice, MySQL. Ma come accennato in precedenza, se si dispone di un sito di conversione elevato, si consiglia una configurazione Master / Slave. Se seguire questo approccio può essere determinato leggendo questo articolo .

Quindi le cache di back-end periferiche, Memcached e Redis. Sui negozi più piccoli, l'archiviazione delle sessioni in un'istanza Memcache e la cache back-end veloce in un'altra offrono buoni vantaggi in termini di prestazioni. Non raccomandiamo di archiviare i tag cache in un backend lento, poiché causa più problemi di quanti ne dia. Quindi, con una configurazione Memcached, dovrai rinunciare alla codifica della cache . Invece, usiamo una configurazione come questa .

Redis non è nativo di Magento, ma con l'estensione di Colin Mollenhour - è una soluzione migliore di Memcache, supporta i tag cache, l'archiviazione delle sessioni e persino l'archiviazione persistente della cache - non è così volatile come Memcache . Ma ha i suoi svantaggi. Abbiamo riscontrato nei negozi di produzione su larga scala (> 500 ordini / ora,> 30k uniques / ora) che la cache (e i tag) possono riempirsi molto rapidamente e una volta raggiunto il punto di saturazione, il meccanismo LRU fallisce un po '( nonostante impostazioni diverse) e provoca un enorme collo di bottiglia immediato. Quindi è prudente eliminare manualmente i vecchi record manualmente.

Quindi quale hardware dovrebbe essere usato per cosa?

Server Web: CPU più veloce, maggior parte dei core della CPU, rapporto tra 2 GB di RAM /
Server DB principale : CPU veloce, I / O su disco più veloce, la maggior parte della RAM

Quindi, quando multi-scopo le tue 3 macchine, il layout migliore sarebbe:

Server 1: Terminator SSL -> Vernice -> Nginx / Apache> PHP
Server 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Server 3: MySQL

Per quanto riguarda la configurazione specifica di ogni applicazione. Bene, questo dipende dalle specifiche hardware, dalla complessità del negozio, dal tipo e dalla natura del visitatore e dall'ampio volume di visitatori.

Sei su un ottimo percorso con quella configurazione del cluster. Consiglio di aggiungere un host cache dedicato per Redis; selezionane uno con elevata potenza della CPU e molta RAM (~ 64 GB).

Ecco l'elenco completo delle configurazioni che ho usato per un cluster LEMP altamente disponibile, tollerante ai guasti, distribuito e bilanciato dal carico. Include app/etc/local.xml, la core_config_datatabella e le configurazioni per MySQL, php-fpm, nginx e Redis. Tutti eseguono Ubuntu 12.04 LTS a 64 bit. Le configurazioni includono molte ottimizzazioni senza inconvenienti.

Mette in risalto

• Utenti amministratori: 46
• Categorie: 2.450 (il più grande ha 2.400 prodotti)
• Entità del prodotto: 101.000
• Prodotti combinati: 484
• Rapporti di prodotto: 54.000
• Disponibile e prodotti configurabili abilitati: 10.100
• Blocchi CMS: 3.100
• Pagine CMS: 1.400

Traffico agosto 2013:

• 40 milioni di visualizzazioni di pagina mensili
• 2,3 milioni di visitatori unici
• 46.000 casse mensili
• 89% dei visitatori dagli Stati Uniti

Host web

Ci sono 10 host dietro firewall hardware ridondanti e ad alta disponibilità e bilanciatori del carico hardware. La maggior parte delle risorse statiche viene scaricata su una rete CDN.

• tempo medio di risposta in tutto il sito: 282 ms
• Risposta FPC media: 48 ms
• media del carico: da 0,6 a 1,0 (nei test, le prestazioni diminuiscono del 35% quando le medie del carico raggiungono ~ 5,0)
• Doppia CPU Intel Xeon E3-1230 V2 a 3,30 GHz (4 core ciascuno)
• 32 GB di RAM DDR3 1333 MHz

moduli

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = modelli
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = produzione
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Host della cache

Esistono due host che eseguono Redis in una configurazione master-slave con failover automatico. Tre istanze Redis (sessioni, back-end e FPC) vengono utilizzate per aumentare la velocità effettiva e fornire una messa a punto dei comportamenti di persistenza.

• 3.000 comandi al secondo
• Tempo medio di risposta di 0,7 ms
• carico medio da 1,0 a 1,5
• Quad Intel Xeon CPU E5-2620 0 a 2,00 GHz (6 core ciascuno)
• RAM DDR3 da 1333 MHz con buffer da 128 GB
• Dischi meccanici, RAID 1, controller hardware

Host del database

Esistono due host che eseguono MySQL 5.6.11 in una configurazione master-slave con failover a caldo.

• 1.500 comandi al secondo
• Tempo di risposta medio di 1,1 ms
• carico medio di 0,1 (master) e 0,4 (slave)
• Quad Intel Xeon CPU E7- 2860 a 2,27 GHz (10 core ciascuno)
• RAM DDR3 da 1333 MHz con buffer da 128 GB
• SSD, RAID 1 + 0, controller hardware
• MySQL 5.6.11 con tcmalloc

Un altro suggerimento sul server per Magento è l'installazione di PHP 5.4 o 5.5 con OPcache . PHP 5.4 è molto più veloce di 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Voglio aggiungere un altro suggerimento importante che ha migliorato la velocità della pagina magento quando non è memorizzato nella cache da vernice e non è abilitato per impostazione predefinita (il tempo di caricamento della pagina del carrello è cambiato da 6sc a 1.5sc).

Attiva la cache delle query mysql in /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

il cache_type lo abilita, la dimensione della cache è il valore utilizzato dalla cache in memoria e il limite della cache è la dimensione massima del risultato della query nella cache

Con la nostra configurazione attuale stiamo ricevendo una risposta iniziale in 400 ms e il documento è completo in 2 secondi (usando una connessione standard di 5 Mbps). La dimensione della nostra homepage è 1mb.

La nostra configurazione si basa su AWS come segue: Abbiamo un'istanza ec2 con un bilanciamento del carico collegato a un database RDS (con failover). Abbiamo anche implementato la cache a pagina intera con un backend della cache redis sia per l'archiviazione della cache sia per l'archiviazione della sessione.

In media abbiamo 300 - 400 visitatori al giorno ma con la cache di redis abilitata abbiamo avuto un utilizzo minimo delle risorse ec2 mantenendo la velocità e riducendo i costi.

Il motivo per cui abbiamo un bilanciamento del carico è che ec2 è configurato per l'avvio automatico di una nuova istanza se, raramente, abbiamo picchi di traffico che la configurazione corrente non è in grado di gestire.