TL; DR - Su MageStack utilizziamo Varnish, Redis (cache), Redis (sessioni) e Eaccelerator / Zend OPCache (a seconda della versione di PHP)
Ne hai già capito la maggior parte.
Il backend della cache, l'archivio sessioni, la cache opcode, la cache a pagina intera e la cache proxy inversa sono completamente diversi.
Puoi usare diverse tecnologie per tutti e puoi usarle TUTTE contemporaneamente (incluso Vernice e un FPC)
Backend della cache
- File (core) Predefinito
- Memcache (Core)
- APC (Core)
- Redis (<1.9 per gentile concessione di Colin Mollenhour)
- MongoDB (modulo per gentile concessione di Colin Mollenhour)
- Rubic (modulo per gentile concessione di Daniel Sloof)
È possibile utilizzare solo un backend della cache.
Contrariamente alla credenza popolare, l'uso di una cache basata sulla memoria non migliorerà le prestazioni. Ma supererà alcuni errori fatali nella cache basata su file predefinito di Magento.
Al momento di scrivere questo messaggio, Redis è la mia raccomandazione.
Negozi di sessioni
- File (core) Predefinito
- Memcache (Core)
- Redis (<1.9 per gentile concessione di Colin Mollenhour)
- MongoDB (modulo per gentile concessione di Colin Mollenhour)
È possibile utilizzare solo un archivio sessioni.
Contrariamente alla credenza popolare, l'uso di un archivio di sessioni basato sulla memoria non migliorerà le prestazioni.
Al momento di scrivere questo messaggio, Redis è la mia raccomandazione.
Cache OpCode
- APC
- XCache
- Eacceleratore (PHP <5.4)
- Zend OPCache (PHP> 5.4)
Puoi effettivamente installare più cache del codice operativo, ma non è raccomandato, né mi aspetto di vedere alcun guadagno.
I miei consigli sono tra parentesi.
Non è necessario installare alcun modulo per sfruttarlo.
Cache proxy inversa
- Vernice
- nginx
- Apache
- … e molti altri
È possibile utilizzare più proxy inversi e, nel contempo, è complesso e incline all'allungamento della cache, può avere dei meriti (ad es. Per impedire lo stampaggio durante lo svuotamento della cache).
Usane uno quando necessario (es. Non per velocizzare un sito lento, ma per ridurre l'utilizzo delle risorse in un sito veloce).
Per sfruttare un proxy inverso, ha bisogno sia dell'abilitazione lato server sia di un modulo per Magento.
Il motivo del modulo è quello di aiutare a controllare la logica di memorizzazione nella cache (ad es. Per dire alla cache cosa dovrebbe e non dovrebbe essere memorizzato nella cache) e anche a gestire il contenuto della cache (ad es. Per attivare l'eliminazione della cache).
Non lo consiglio a nessuno a meno che tu non abbia una comprensione totale di ciò che stai facendo. Una configurazione errata dei proxy inversi può rompere le informazioni di intestazione, può causare la perdita della sessione, la condivisione della sessione, il contenuto non aggiornato, applicare limiti aggiuntivi per caricare tempo / buffer, consumare risorse aggiuntive ecc.
Cache a pagina intera
- EE FPC
- ... molti altri (tramite moduli)
Usane uno quando necessario (es. Non per velocizzare un sito lento, ma per ridurre l'utilizzo delle risorse in un sito veloce).
Contrariamente alla credenza popolare, puoi (e dovresti) usare un FPC insieme a una cache proxy inversa. I due risolvono problemi diversi e hanno capacità diverse.
Gli FPC possono sfruttare più intelligenza, perché hanno accesso diretto alla sessione degli utenti e al core di Magento, mentre un proxy inverso non è a conoscenza dell'applicazione (è abbastanza stupido nel modo in cui funziona) - quindi i due si completano a vicenda, non competono tra loro .
Vale a dire. Non pensare a Vernice o FPC, pensa a Vernice e FPC.