Perché Magento è così lento? [chiuso]

138

Magento di solito è così terribilmente lento?

Questa è la mia prima esperienza con esso e il pannello di amministrazione richiede semplicemente anni per caricare e salvare le modifiche. È un'installazione predefinita con i dati di test.

Il server in cui è ospitato serve altri siti non Magento in modo super veloce. Cos'è il codice PHP utilizzato da Magento che lo rende così lento e cosa si può fare per risolverlo?

php magento optimization

— mr-euro
fonte

12

Su quale hardware lo stai eseguendo? Magento ha bisogno di un serio supporto hardware nella mia esperienza.

— jitter,

3

Non sto chiedendo supporto, ma codice. La mia speranza era che qualcuno lo avesse sperimentato in passato e avesse ottimizzato il codice per evitare un comportamento così lento. Non ho un frammento specifico di codice a cui puntare poiché è applicabile su tutto il sito. Dovrò approfondire la questione.

— sig. Euro

18

Magento ha oltre 6000 file di classe ed è costruito per uso aziendale non per uso domestico. Senza APC non pensare all'installazione. Non lo consiglio a piccoli negozi.

— Elzo Valugi

1

Per quanto riguarda la tua bandiera, @Jonesome: questa domanda è molto ampia e ... probabilmente un po 'datata a questo punto. Detto questo, ora abbiamo un sito dedicato ai problemi di Magento ( Magento ), che sarebbe probabilmente una buona risorsa per chiunque lavori per ottimizzare la propria configurazione.

— Shog9

1

@ Shog9 Gestisco un team che sviluppa e supporta componenti aggiuntivi per Magento. Posso dirti che questo problema esatto si presenta quasi ogni giorno. Magento non è un'app lampada "normale", in quanto richiede molte risorse. Questa discussione è importante. Chiudendolo, questa conversazione comune viene interrotta da SO, il che è un peccato per tutti.

— Jonesome ripristina Monica il

184

Sono stato solo tangenzialmente coinvolto nell'ottimizzazione di Magento per le prestazioni, ma ecco alcuni motivi per cui il sistema è così lento

Parti di Magento utilizzano un sistema di database EAV implementato su MySQL. Ciò significa che interrogare per una singola "cosa" spesso significa interrogare più righe
Ci sono molte cose dietro le quinte (configurazione dell'applicazione, configurazione del sistema, configurazione del layout, ecc.) Che coinvolgono la creazione di giganteschi alberi XML in memoria e quindi "l'interrogazione" di quegli stessi alberi per informazioni. Ciò richiede sia memoria (memorizzazione degli alberi) sia CPU (analisi degli alberi). Alcuni di questi (specialmente l'albero del layout) sono enormi. Inoltre, a meno che non sia attiva la memorizzazione nella cache, questi alberi vengono creati dai file sul disco e su ogni richiesta .
Magento utilizza il suo sistema di configurazione per consentire di sovrascrivere le classi. Questa è una funzionalità potente, ma significa che ogni volta che viene istanziato un modello, un helper o un controller, è necessario eseguire ulteriori istruzioni PHP per determinare se è necessario un file di classe originale o un file di classe di sostituzione. Questo aggiunge.
Oltre al sistema di layout, il sistema di template di Magento comporta un sacco di rendering ricorsivo. Questo aggiunge.

In generale, gli ingegneri Magento avevano il compito, in primo luogo, di costruire il sistema più flessibile e personalizzabile possibile, e si preoccupavano delle prestazioni in seguito.

La prima cosa che puoi fare per garantire prestazioni migliori è attivare la memorizzazione nella cache (Sistema -> Gestione cache). Questo alleggerirà alcuni dei blocchi CPU / disco che si verificano mentre Magento sta costruendo i suoi vari alberi XML.

La seconda cosa che vorrai fare è assicurarti che il tuo host e il team operativo abbiano esperienza di ottimizzazione delle prestazioni Magento. Se stai facendo affidamento sul piano da $ 7 / mese per farti vedere, beh, buona fortuna con quello.

— Alan Storm
fonte

10

Grazie per l'ampia spiegazione. Magento è davvero molto potente e consente flessibilità. Inizialmente pensavo che fosse semplicemente il DB a scrivere lo stallo a causa di un SQL scritto male, ma ora mi rendo conto che c'è molto altro dietro le quinte che inizialmente si aspettava. Nota: la memorizzazione nella cache è stata disabilitata a causa dell'aggiunta di prodotti da parte del proprietario del negozio. Quando la cache era attiva, si lamentava del fatto che i prodotti non apparissero costringendomi a disabilitare la memorizzazione nella cache durante l'apertura del negozio. È ospitato su un server dedicato, ma sembra che dovrò spostare Magento nella sua casella esclusiva.

— sig. Euro

4

L'ho profilato qualche tempo fa con XHProf. L'analisi XML ha richiesto molto tempo - penso che tu sia perfetto con questo elenco.

— Morgan Tocker,

1

Mi chiedevo se eseguire Magento su HHVM avrebbe migliorato la situazione. L'ultima volta che ho controllato HHVM non supporta Magento, ma se fosse fatto, sarebbe d'aiuto?

— Bharadwaj Srigiriraju,

1

Questo spiega molto. Sapere è metà della battaglia. Non vedo come questo non possa essere considerato costruttivo.

— flcoder,

Non dimenticare di ottimizzare i file del caricatore automatico del compositore (vedi le linee guida sulle prestazioni di Magento), se usi il compositore e, per Magento2, attiva la modalità di produzione! Anche Varnish è un'ottima idea, a condizione che l'applicazione non abbia problemi con la cache a pagina intera.

— Dmitri Sologoubenko il

54

Oltre ai consigli di Alan Storm sulla memorizzazione nella cache, ci sono due cose che ti consiglio in particolare di esaminare in relazione alla memorizzazione nella cache:

- Assicurarsi che la memorizzazione nella cache sia memorizzata nella cache anziché sul disco.

Mi occupo di un paio di installazioni di Magento e, una volta ottenuto qualsiasi tipo di carico sul sistema, memcached inizia a funzionare molto più velocemente. Ed è facile cambiarlo (relativamente al fare almeno altre cose magento!)

Il buon punto di partenza è qui: http://www.magentocommerce.com/boards/viewthread/12998/P30/ - ma se non hai mai usato memcached prima, vale la pena guardare anche alcune informazioni generali su di esso.

- Abilita la cache del modello / vista.

Questo è un buon articolo: http://inchoo.net/ecommerce/magento/magento-block-caching/

Ce ne sono di buoni anche sul sito di Magento (blocco di Google Magento nella cache), ma al momento è inattivo.

Per aggiungere i miei due centesimi alla cache dei blocchi, ti consiglio di creare i tuoi blocchi in / app / code / local, estendere quelli principali e definire i parametri della cache, denominarli xxx_Cache e quindi aggiornare il layout per utilizzare questi blocchi di quelli fondamentali. In questo modo, eviti di perdere le modifiche o di rompere il sistema quando aggiorni magento.

— benlumley
fonte

3

Grazie per i punti. Darò un'occhiata a memcached che non avevo mai usato in produzione prima. Buona idea anche sulla clonazione dei blocchi.

— euro

3

Dico ciò che ha detto Benlumbey, non uso memcached mentre eseguo Windows Server, ma conservo la directory / var in un disco a stato solido e questo ha fatto una grande differenza per me.

— Rick J,

@rickj - sì, tutto ciò che rende la cartella ./var più veloce sicuramente aiuta, ho provato a usare tmpfs anche prima di essere memorizzato nella cache, e ho ottenuto anche una spinta decente da quello.

— Benlumley,

Aggiungerei per usare la cache apc solo per un singolo nodo in quanto sembra avere un sovraccarico minore di quello memcached per l'ambiente multi-nodo.

— sbditto85,

2

Sì vero. Ma ci sono alcuni avvertimenti lì, a seconda di come esegui PHP, puoi finire con una cache APC separata per ogni processo PHP - che diventa ancora meno ottimale se stai ciclando i tuoi processi PHP ogni X richieste.

— Benlumley,

23

Se non l'hai ancora visto, Magento e Rackspace si sono uniti per creare un white paper sull'ottimizzazione delle prestazioni di Magento. È eccellente https://support.rackspace.com/whitepapers/building-secure-scalable-and-highly-available-magento-stores-powered-by-rackspace-solutions/

--- modificare ---

Un'altra grande risorsa, recentemente disponibile (ottobre 2011) è: http://www.sessiondigital.com/assets/Uploads/Mag-Perf-WP-final.pdf

(Grazie a Alan Storm per questo.)

— Laizer
fonte

Grazie per l'aggiornamento, lo leggerò più avanti in seguito.

— sig. Euro

2

Quel secondo collegamento è ora morto.

— Laizer,

1

Anche il primo link è morto.

— Edward,

I collegamenti sono interrotti. Ner

— Ner,

1

Link diretto per il Whitepaper di Rackspace (link n. 1).

— Levi Figueira,

17

C'è forse anche una ragione non ovvia per cui l'interfaccia di amministrazione è molto lenta. Magento ha un modulo chiamato Mage_AdminNotification. Prova a disabilitare quell'estensione. Perché ciò che fa è interrogare magentocommerce.com per nuovi messaggi di aggiornamento. Se i loro server sono lenti, la pagina di amministrazione attende ed è in effetti lenta a causa del ritardo della rete e del caricamento delle notizie esterne. Se hai protetto la tua connessione al server in uscita attraverso un firewall, questo può essere ancora più frustrante, poiché l'interfaccia di amministrazione attenderà il timeout quando non può raggiungere magentocommerce.com

Per disabilitarlo: vai su Sistema -> Configurazione, scorri verso il basso e premi Avanzate (nella sezione Avanzate). Ora disabilita Mage_AdminNotificatione salva!

— Sam Figueroa
fonte

4

Ciò ha fatto una differenza significativa nelle prestazioni nel mio ambiente di sviluppo locale, il che mi ha sempre frustrato per quanto lentamente funzionasse su una scatola di sviluppo molto veloce. Grazie!

— random_user_name

In Magento2: Negozi-> Configurazione-> Avanzate-> Avanzate, quindi disabilita Mage_AdminNotification.

— Scott C Wilson,

6

Ho solo un'esperienza superficiale con Magento. L'ho installato su un grid-server condiviso e il caricamento della pagina era triste ~ 5 + secondi. Su un lark, l'ho installato sul mio server dedicato ottimizzato per siti CMS e mi è sembrato molto, molto scattante.

Il mio hosting dedicato aveva ~ 10 Joomla! siti e un sito VBullitin in esecuzione.

La mia ipotesi è che non sarà solo performante sull'hosting condiviso. L'abbonamento in eccesso non consentirà a Magento di disporre di risorse sufficienti per l'esecuzione come dovrebbe.

— creuzerm
fonte

6

Sono più coinvolto nell'ottimizzazione del server gestito nella mia azienda, ma potrei avere alcuni suggerimenti per te. Innanzitutto, puoi guardare il codice più da vicino usando la funzione di tracciamento del codice del server Zend. Ti permetterà di vedere dove e quando le cose si sporcano.

Condivido totalmente la considerazione di Benlumley riguardo alla cache. La maggior parte dei siti che ospitiamo non ha nemmeno abilitato il blocco nella cache. Questa cache deve essere esplicitamente chiamata e non "assunta". Quindi, se il tuo codice non ha ancora preso parte a questo meccanismo, è sicuramente qualcosa che vuoi provare. Se hai una versione EE, puoi ottenere la pagina Completa per ottenere il meglio dalla bestia.

Un proxy inverso aiuterà anche molto. Memorizzerà nella cache le risorse statiche, riducendo significativamente la pressione sullo stack di interpretazione php dei server frontali.

Non dimenticare di scrivere le sessioni e la cache Magento su un disco RAM. Questo ti porterà sicuramente ad un altro livello di spettacoli.

C'è ancora molto da dire qui, ma sto esaurendo il tempo. Devi sapere che un buon sito, ben codificato in una versione 1.4.1 CE, in esecuzione su un server RAM 2x5650 Xeon + 16 GB e con un Rproxy in cima può portare fino a 50.000 visitatori unici al giorno con pagine lisce per tutti .

— Kameo
fonte

5

Il passaggio da Apache a LiteSpeed ci ha aiutato molto. Oltre a: Modifica delle impostazioni di MySQL, installazione di Fooman Speedster (modulo per comprimere / combinare file js e css) e installazione di APC. Magento ha anche pubblicato un white paper su come ottenere le migliori prestazioni dall'edizione enterprise, ma è ugualmente applicabile alle altre versioni: http://www.magentocommerce.com/whitepaper/

— Jonathan
fonte

4

Ci sono molte ragioni per cui il tuo carrello Magento potrebbe essere lento, ma non ci sono scuse perché ci sono una varietà di modi per sollevare il problema e renderlo dannatamente veloce. Abilitare Gzip modificando il file htaccess è un inizio. Puoi anche installare l'estensione fooman speedster. Il tipo di server utilizzato determinerà anche la velocità del tuo negozio. Altri suggerimenti e una spiegazione migliore qui http://www.interactone.com/how-to-speed-up-magento/

— Tommaso
fonte

4

Quando ho installato per la prima volta avevo pagine che impiegavano 30 secondi per caricarsi. Il mio server non era al massimo in ram o processore, quindi non sapevo cosa fare. Guardando il pannello di rete di Firebug stava caricando circa 100 file per pagina e ognuno ha impiegato molto tempo per connettersi. Dopo aver installato fooman speedster e il gzip nei carichi htaccess i tempi sono scesi a 3 secondi, come se fossero stati su altri carrelli della spesa sul mio server.

— Scott
fonte

3

Magento è molto lento perché la progettazione del database non è molto buona. Il codice è un casino e molto difficile da aggiornare e ottimizzare. Quindi tutte le ottimizzazioni vengono eseguite tramite cache anziché tramite codice.

D'altro canto. È un negozio online con molti strumenti. Quindi, se hai bisogno di un webshop flessibile, acquista un server molto potente e starai bene.

— sviluppatore
fonte

1

Il design del database è in realtà molto buono e flessibile.

— Nero,

3

dipenderà anche dalla funzionalità rispetto alle prestazioni.

Le prestazioni non elaborate si ottengono utilizzando nginx, php-fpm, memcached, apc e un server progettato correttamente.

Funzionalità come le prestazioni plesk e magento potrebbero essere gestite prendendo in prospettiva l'intera infrastruttura durante la progettazione di un cloud di prestazioni magento.

— ProContractors
fonte