Pourquoi Magento est-il si lent? [fermé]

139

Magento est-il généralement si terriblement lent?

C'est ma première expérience avec celui-ci et le panneau d'administration prend simplement du temps à charger et enregistrer les modifications. Il s'agit d'une installation par défaut avec les données de test.

Le serveur sur lequel il est hébergé sert très rapidement d'autres sites non Magento. Qu'est-ce qui le rend si lent dans le code PHP utilisé par Magento et que peut-on faire pour y remédier?

php magento optimization

— mr-euro
source

12

Sur quel matériel l'exécutez-vous? Magento a besoin d'un support matériel sérieux d'après mon expérience.

— gigue du

3

Je ne demande pas de support, mais du code. J'espérais que quelqu'un avait vécu cela dans le passé et avait optimisé le code pour éviter un comportement aussi lent. Je n'ai pas d'extrait de code spécifique à pointer car il est applicable sur l'ensemble du site. Je devrai approfondir la question.

— mr-euro

18

Magento a plus de 6000 fichiers de classe et est conçu pour un usage professionnel et non pour un usage domestique. Sans APC, ne pensez pas à l'installer. Je ne le recommande pas pour les petits magasins.

— Elzo Valugi

1

Concernant votre drapeau, @Jonesome: cette question est très large et ... probablement un peu datée à ce stade. Cela dit, nous avons maintenant un site dédié aux problèmes de Magento ( Magento ), qui serait probablement une bonne ressource pour quiconque travaille à optimiser sa configuration.

— Shog9

1

@ Shog9 Je gère une équipe qui développe et supporte des modules complémentaires pour magento. Je peux vous dire que ce problème précis survient presque quotidiennement. Magento n'est pas une application lampe "normale", en ce sens qu'elle est très (très) gourmande en ressources. Ce fil est important. Le fermer force cette conversation commune hors de SO, ce qui est regrettable pour tous.

— Jonesome réintègre Monica

184

Je n'ai été impliqué que de manière tangentielle dans l'optimisation de Magento pour les performances, mais voici quelques raisons pour lesquelles le système est si lent

Certaines parties de Magento utilisent un système de base de données EAV implémenté au-dessus de MySQL. Cela signifie qu'interroger une seule "chose" signifie souvent interroger plusieurs lignes
Il y a beaucoup de choses dans les coulisses (configuration de l'application, configuration du système, configuration de la mise en page, etc.) qui impliquent de construire des arbres XML géants en mémoire, puis de «demander» ces mêmes arbres pour obtenir des informations. Cela prend à la fois de la mémoire (stockage des arbres) et du processeur (analyse des arbres). Certains d'entre eux (en particulier l'arbre de mise en page) sont énormes. De plus, sauf si la mise en cache est activée, ces arborescences sont construites à partir de fichiers sur disque et à chaque demande .
Magento utilise son système de configuration pour vous permettre de remplacer les classes. C'est une fonctionnalité puissante, mais cela signifie qu'à chaque fois qu'un modèle, un assistant ou un contrôleur est instancié, des instructions PHP supplémentaires doivent être exécutées pour déterminer si un fichier de classe d'origine ou un fichier de classe de remplacement est nécessaire. Cela s'additionne.
Outre le système de mise en page, le système de modèles de Magento implique beaucoup de rendu récursif. Cela s'additionne.

En général, les ingénieurs Magento ont été chargés, avant tout, de créer le système le plus flexible et personnalisable possible, et de se soucier des performances plus tard.

La première chose que vous pouvez faire pour garantir de meilleures performances est d'activer la mise en cache (Système -> Gestion du cache). Cela soulagera une partie du blocage CPU / disque qui se produit pendant que Magento construit ses différentes arborescences XML.

La deuxième chose que vous voudrez faire est de vous assurer que votre hôte et votre équipe d'exploitation ont l'expérience du réglage des performances de Magento. Si vous comptez sur le plan de 7 $ / mois pour vous aider, bonne chance.

— Alan Storm
source

10

Merci pour l'explication détaillée. Magento est en effet très puissant tout en permettant de la flexibilité. Au départ, je pensais que c'était simplement le blocage des écritures de la base de données en raison d'un SQL mal écrit, mais je me rends compte maintenant qu'il se passe beaucoup plus dans les coulisses que prévu initialement. À noter: la mise en cache a été désactivée en raison de l'ajout de produits par le propriétaire de la boutique. Lorsque le cache était activé, il s'est plaint que les produits n'apparaissaient pas, ce qui m'obligeait à désactiver la mise en cache pendant la configuration de la boutique. Il est hébergé sur un serveur dédié, mais il semble que je devrai déplacer Magento vers sa propre boîte exclusive.

— mr-euro

4

Je l'ai profilé il y a quelque temps avec XHProf. L'analyse XML a pris énormément de temps - je pense que vous êtes sur place avec cette liste.

— Morgan Tocker

1

Je me demandais si l'exécution de Magento sur HHVM améliorerait la situation. La dernière fois, j'ai vérifié que HHVM ne prend pas en charge Magento, mais si cela était fait, cela aiderait-il?

— Bharadwaj Srigiriraju

1

Cela explique beaucoup de choses. Savoir, c'est la moitié de la bataille. Je ne vois pas comment cela ne pourrait pas être considéré comme constructif.

— flcoder

N'oubliez pas d'optimiser les fichiers du chargeur automatique de compositeur (voir les directives de performance de magento), si vous utilisez composer, et - pour Magento2 - passez en mode production! Varnish est également une très bonne idée, à condition que votre application n'ait pas de problèmes avec le cache pleine page.

— Dmitri Sologoubenko

54

En plus des recommandations d'Alan Storm sur la mise en cache, il y a deux choses que je vous recommande spécifiquement d'examiner liées à la mise en cache:

- Assurez-vous que la mise en cache est dans Memcached, plutôt que sur le disque.

Je m'occupe de quelques installations de magento, et une fois que vous avez une charge quelconque sur le système, memcached commence à fonctionner beaucoup plus rapidement. Et c'est très facile de le changer (par rapport à d'autres choses magento au moins!)

Un bon point de départ est ici: http://www.magentocommerce.com/boards/viewthread/12998/P30/ - mais si vous n'avez pas du tout utilisé memcached auparavant, il vaut la peine de consulter quelques informations générales à ce sujet.

- Activer la mise en cache des modèles / vues.

C'est un bon article: http://inchoo.net/ecommerce/magento/magento-block-caching/

Il y en a aussi de bons sur le site magento (mise en cache de bloc google magento), mais c'est en panne pour le moment.

Pour ajouter mes deux cents à la mise en cache des blocs, je vous conseille de créer vos propres blocs dans / app / code / local, en étendant les blocs principaux et en définissant les paramètres du cache, nommez-les xxx_Cache, puis mettez à jour votre mise en page pour utiliser ces blocs à la place des principaux. De cette façon, vous évitez de perdre vos modifications ou de casser le système lorsque vous mettez à jour magento.

— Benlumley
source

3

Thx pour les points. Je vais jeter un oeil à memcached que je n'ai jamais utilisé en production auparavant. Bonne idée de cloner les blocs aussi.

— mr-euro

3

Je confirme ce que Benlumbey a dit, je n'utilise pas memcached car j'exécute le serveur Windows, mais je stocke le répertoire / var dans un disque SSD et cela a fait une grande différence pour moi.

— Rick J

@rickj - ouais, tout ce qui permet de rendre le dossier ./var plus rapide aide définitivement, j'ai également essayé d'utiliser tmpfs avant memcached, et j'ai également eu un bon coup de pouce.

— benlumley

J'ajouterais à utiliser le cache apc pour un seul nœud car il semble avoir moins de frais généraux que Memcached pour un environnement multi-nœuds.

— sbditto85

2

Oui c'est vrai. Mais il y a quelques mises en garde là-bas, selon la façon dont vous exécutez PHP, vous pouvez vous retrouver avec un cache APC séparé pour chaque processus PHP - ce qui devient encore moins optimal si vous cyclez vos processus PHP toutes les requêtes X.

— benlumley

23

Si vous ne l'avez pas encore vu, Magento et Rackspace se sont associés pour créer un livre blanc sur le réglage des performances de Magento. C'est excellent. https://support.rackspace.com/whitepapers/building-secure-scalable-and-highly-available-magento-stores-powered-by-rackspace-solutions/

--- Éditer ---

Une autre excellente ressource, nouvellement disponible (octobre 2011) est: http://www.sessiondigital.com/assets/Uploads/Mag-Perf-WP-final.pdf

(Merci à Alan Storm pour celui-ci.)

— Laizer
source

Merci pour la mise à jour, je la lirai en détail plus tard.

— mr-euro

2

Ce deuxième lien est maintenant mort.

— Laizer

1

Le premier lien est mort aussi.

— Edward

Les liens sont rompus. Ner

— Ner

1

Lien direct vers le livre blanc de Rackspace (lien n ° 1).

— Levi Figueira

17

Il y a peut-être aussi une raison très peu évidente pour laquelle votre interface d'administration est très lente. Magento a un module nommé Mage_AdminNotification. Essayez de désactiver ce poste. Parce que ce qu'il fait, c'est interroger magentocommerce.com pour les nouveaux messages de mise à jour. Si leurs serveurs sont lents, votre page d'administration attend et est en effet lente à cause du retard du réseau et du chargement des news externes. Si vous avez sécurisé votre connexion serveur sortante via un pare-feu, cela peut être encore plus frustrant, car l'interface d'administration attendra le délai d'expiration lorsqu'elle ne pourra pas atteindre magentocommerce.com

Pour le désactiver: allez dans Système -> Configuration, faites défiler vers le bas et appuyez sur Avancé (dans la section Avancé). Désactivez Mage_AdminNotificationet enregistrez maintenant !

— Sam Figueroa
source

4

Cela a fait une différence significative dans les performances de mon environnement de développement local, ce qui m'a toujours frustré de la lenteur avec laquelle il fonctionnait sur une boîte de développement très rapide. Je vous remercie!

— random_user_name

Dans Magento2: Stores-> Configuration-> Advanced-> Advanced, puis désactivez Mage_AdminNotification.

— Scott C Wilson

6

Je n'ai qu'une expérience superficielle avec Magento. Je l'ai installé sur un serveur de grille partagé et le chargement de la page était lamentable ~ 5 + secondes. Sur une alouette, je l'ai installé sur mon serveur dédié optimisé pour les sites CMS, et cela me semblait très, très accrocheur.

Mon hébergement dédié avait ~ 10 Joomla! sites et un site VBullitin en cours d'exécution.

Je suppose que cela ne sera tout simplement pas performant sur l'hébergement partagé. Le surabonnement ne permettra tout simplement pas à Magento de fonctionner comme il se doit.

— Creuzerm
source

6

Je suis plus impliqué dans l'optimisation des serveurs gérés de mon entreprise mais j'ai peut-être quelques conseils à vous donner. Tout d'abord, vous pouvez regarder le code de plus près en utilisant la fonction de traçage de code du serveur Zend. Cela vous permettra de voir où et quand les choses se salissent.

Je partage totalement la considération de Benlumley concernant le cache. La plupart des sites que nous hébergeons ne disposent même pas de l'activation de la mise en cache de bloc. Ce cache doit être explicitement appelé et non "supposé". Donc, si votre code n'a pas encore participé à ce mécanisme, c'est quelque chose que vous voulez absolument essayer. Si vous avez une version EE, vous pouvez obtenir la page complète afin de tirer le meilleur parti de la bête.

Un proxy inverse aidera également beaucoup. Il mettra en cache les ressources statiques, réduisant considérablement la pression sur la pile d'interprétation php de vos serveurs frontaux.

N'oubliez pas d'écrire les sessions et le cache Magento sur un disque RAM. Cela vous amènera certainement à un autre niveau de performances.

Il y a encore beaucoup à dire ici mais je manque de temps. Il faut savoir qu'un bon site, bien codé dans une version 1.4.1 CE, fonctionnant sur un serveur 2x5650 Xeon + 16 Go de RAM et ayant un Rproxy sur le dessus peut prendre jusqu'à 50000 visiteurs uniques par jour avec des pages fluides pour tout le monde .

— kameo
source

5

Le passage d'Apache à LiteSpeed nous a beaucoup aidés. En plus de: Modifier les paramètres de MySQL, installer Fooman Speedster (module pour compresser / combiner les fichiers js et css) et installer APC. Magento a également publié un livre blanc sur la façon d'obtenir les meilleures performances de l'édition entreprise, mais il est également applicable aux autres versions: http://www.magentocommerce.com/whitepaper/

— Jonathan
source

4

Il existe de nombreuses raisons pour lesquelles votre panier d'achat Magento pourrait être lent, mais aucune excuse car il existe une variété de façons de résoudre le problème et de le rendre sacrément rapide. Activer Gzip en modifiant votre fichier htaccess est un début. Vous pouvez également installer l'extension fooman speedster. Le type de serveur utilisé déterminera également la vitesse de votre boutique. Plus de conseils et une meilleure explication ici http://www.interactone.com/how-to-speed-up-magento/

— Thomas
source

4

Lors de la première installation, j'avais des pages qui prenaient 30 secondes à charger. Mon serveur n'était pas au maximum en RAM ou en processeur, donc je ne savais pas quoi faire. En regardant le panneau net de Firebug, il chargeait environ 100 fichiers par page, et chacun prenait beaucoup de temps pour se connecter. Après avoir installé fooman speedster et le gzip dans les temps de chargement htaccess, les temps de chargement étaient réduits à 3 secondes, comme ils l'avaient été sur d'autres paniers sur mon serveur.

— Scott
source

3

Magento est très lent car la conception de la base de données n'est pas très bonne. Le code est un gâchis et très difficile à mettre à jour et à optimiser. Ainsi, toutes les optimisations sont effectuées via le cache au lieu du code.

D'autre part. C'est une boutique en ligne avec de nombreux outils. Donc, si vous avez besoin d'une boutique en ligne flexible, achetez simplement un serveur très puissant et tout ira bien.

— développeur
source

1

La conception de la base de données est en fait très bonne et flexible.

— Noir du

3

cela se résumera également à la fonctionnalité par rapport aux performances.

Les performances brutes sont obtenues en utilisant nginx, php-fpm, memcached, apc et un serveur correctement conçu.

Des fonctionnalités telles que les performances de plesk et magento pourraient être gérées en prenant toute l'infrastructure en perspective lors de la conception d'un cloud de performance magento.

— ProContractors
source