Vous entrez dans un monde d'optimisation large et large ici et il n'y a certainement pas une approche unique pour tous.
Définir les performances
Voulez-vous dire le temps de chargement de la page pour un seul utilisateur, ou la capacité globale / concurrence totale? Les deux sont très différents - et ne sont pas strictement liés. Il est tout à fait possible d'avoir un magasin rapide avec une capacité limitée; ou un magasin lent avec beaucoup de capacité.
Ainsi, lorsque vous abordez l'un ou l'autre type de performances:
- Temps de chargement de page perçu par un seul utilisateur
- Capacité totale / simultanéité
Vous devez vous attaquer à chacun indépendamment avec ses propres solutions - d'autant plus que chacun a ses propres goulots d'étranglement.
Supposons que vous êtes avec un hôte compétent qui a déjà configuré les autres aspects de votre serveur de manière optimale pour votre magasin.
Temps de chargement de page perçu par un seul utilisateur
Est-ce que MySQL est le goulot d'étranglement
. Pas directement. Tout dépend de la latence, dans la majorité des cas lors du test du temps de chargement des pages - seuls les caches seront touchés. La clé ici est donc de minimiser la latence.
- Ajustez les tailles de cache MySQL de manière appropriée (il n'y a pas de bonne réponse, nous ajustons les paramètres de manière complètement différente, mensuellement, par magasin)
- Réduisez la latence du réseau. Pour les trames de 64 octets; 51,2µs pour 10Mbps, 5,12µs pour 100Mbps et 4,096µs pour 1Gbps. Cela donne une amélioration de 20% simplement en passant de 100Mbps à 1Gbps. s1
- Augmentez la capacité du réseau. Vous seriez surpris des nombreux mégaoctets par seconde échangés entre un serveur Web et un serveur de base de données, généralement supérieurs à 10 Mo / s - un minimum de 100 Mo / s est donc requis s1 . Ou déplacez simplement le serveur DB localement.
- Utilisation de SOLR. Les moteurs externes sont parfois mieux adaptés, SOLR est certainement plus rapide pour les catalogues plus grands (et je voudrais souligner, les catalogues plus grands ). Même SOLR non réglé produira une navigation en couches et des résultats de recherche plus rapidement que MySQL.
Mais ces changements auront un impact si fractionnaire sur le temps de chargement des pages - où le goulot d'étranglement est vraiment ailleurs.
- Réglez l'application. Magento a quelques bugs assez importants avec la façon dont il construit les collections et les met en cache; nous avons rencontré un certain nombre de gros problèmes de code de base qui peuvent entraver les performances. Dans certains cas, la simple suppression de l'affichage du nombre de produits sur les résultats de navigation en couches a réduit de 2 secondes le chargement d'une grande collection.
- Consultez les journaux lents de MySQL. Vérifiez les requêtes lentes et ajoutez des index si nécessaire. La différence entre l'exécution d'une requête complexe avec plusieurs jointures avec et sans index appropriés peut être de plusieurs dizaines de secondes .
L'application est le goulot d'étranglement. Pas le logiciel. Donc, simplement améliorer le code principal ou rendre votre modèle moins lourd aura un effet beaucoup plus spectaculaire sur les performances que TOUT changement de configuration MySQL.
Avec quoi ne nous embêterions-nous pas
- Changer le moteur de stockage. MariaDB et Percona partagent le même moteur InnoDB - Percona XtraDB. Ils peuvent être traités comme une seule et même chose. En termes de temps d'exécution d'une requête unique, les performances refléteront exactement une version MySQL vanille. Cela entre en jeu sous charge / concurrence.
- Exécuter un esclave MySQL. Cela n'améliorera pas les performances à moins que l'esclave ne soit physiquement plus proche (du point de vue du réseau) ou que l'esclave ait un meilleur matériel que le maître. Cela entre en jeu sous charge / concurrence.
- Exécution d'un serveur de base de données externe. C'est de loin le pire conseil que nous voyons à plusieurs reprises donné par de nombreux hôtes / agences. Jusqu'à ce que vous ayez atteint un plafond de matériel / ressources ou que vous ayez plusieurs serveurs Web (lire: haute disponibilité), MySQL sur la machine locale pour un magasin Magento est une bonne idée. Il supprime tous les frais généraux et la latence du réseau. Même un réseau à 100 Gbit / s (oui, cent gigabits par seconde) ne sera pas comparable à un socket Unix local pour le volume brut, le débit et la latence.
s1 Pour les serveurs de base de données séparés uniquement. Ne s'applique pas aux serveurs DB locaux.
Capacité totale / simultanéité
MySQL est-il le goulot d'étranglement
Peut-être. Mais seulement une fois que vous avez cloué vos performances et vos capacités PHP au point où MySQL ralentit les choses. Si vous avez Varnish et FPC correctement configurés (ne nous dites pas combien de tentatives ont échoué avec l'un ou l'autre) - alors MySQL devient un goulot d'étranglement.
Donc, en plus des modifications ci-dessus.
- Changer le moteur MySQL. XtraDB peut exceller sous charge et présente de réels avantages par rapport à une distribution MySQL d'origine.
- Restez à jour avec MySQL. 5.5 fonctionne mieux que 5.0 sous charge.
- Changez le pilote PHP MySQL. PHP 5.3 et les versions plus récentes ont un pilote MySQL natif, mais dans certaines circonstances, nous avons trouvé PHP 5.2 avec le pilote séparé pour surpasser MySQLND pour Magento.Testez-le par vous-même
- Changer de moteur de recherche. Déplacer la recherche vers SOLR / Sphinx (ou même certains services externes tiers) peut vraiment alléger le fardeau de la charge non transactionnelle (c'est-à-dire les personnes qui ne passent pas de commandes)
- Changer le moteur de navigation en couches. Encore une fois, SOLR est un moteur brillant pour la navigation en couches et en raison de sa nature non verrouillable est beaucoup plus rapide que MySQL.
- Ajoutez un esclave MySQL. Cela ne Parcouru (non transactionnel) charge, mais ne vous aidera pas traiter plus de commandes par heure - car il est tributaire de la maîtrise de processus et de reproduire ces données
Avec quoi ne nous embêterions-nous pas
- Maître / Maître. En raison du point de basculement assez élevé de la saturation matérielle d'une configuration maître / esclave (plus de 1000 commandes par heure) - nous n'avons jamais trouvé nécessaire d'utiliser Master / Master en production. Nous avons effectué des tests approfondis, mais nous ne l'avons jamais trouvé avantageux du point de vue des performances et avec les risques et problèmes inhérents à Master / Master, cela n'en vaut tout simplement pas la peine.
Évolutivité en lecture et en écriture
Le dernier paragraphe mène vraiment à un domaine clé de l'évolutivité en lecture et en écriture. La mise à l'échelle de la lecture peut être effectuée de manière assez infinie sans trop de complications avec l'ajout de plus en plus d'esclaves.
Étant donné que le ratio de lectures / écritures de Magento est d'environ 0,1% - les écritures ne devraient pas être très préoccupantes. C'est pourquoi je n'ai pas pris la peine de mentionner MySQL Cluster et ses fonctionnalités intelligentes comme le partage automatique (séparation des tables sur des machines distinctes).
Matériel, matériel, matériel
Le matériel est facilement la réponse la plus rapide en matière d'amélioration, donc je ne l'ai délibérément pas mentionné ci-dessus dans les deux scénarios.
Mais tous les changements logiciels dans le monde ne feront aucune différence si votre matériel sous-jacent est insuffisant. Cela pourrait signifier ...
- Commutateurs de faible qualité avec tampons limités
- Liens réseau trop saturés
- Serveurs géographiquement éloignés
- Mauvaise qualité de service / CoS du réseau
- Quantité totale limitée de RAM
- Mémoire RAM à faible bande passante
- Sous-système de disque dur à faibles IOP
- Contrôleur RAID logiciel
- CPU à faible vitesse d'horloge
- Jeu de puces à faible bande passante
- Virtualisation matérielle (presque tous les types à l'exception de la virtualisation au niveau du noyau)
De nos jours, il y a un plafond vraiment élevé sur la hauteur à laquelle vous pouvez réellement évoluer sur le matériel. Ignorons le mythe de la mise à l'échelle infinie "dans le cloud" car le matériel cloud a tendance à être assez médiocre. Par exemple, les modèles phares d'Amazon ne sont que 12 cœurs à 3,3 GHz. Mais en dehors de cela, il y a des serveurs très puissants disponibles - notre serveur supérieur a 160 cœurs et 2 To (oui, des téraoctets) de RAM. Nous n'avons encore vu personne dépasser les capacités de cela.
Vous disposez donc d'un vaste champ d'application pour la mise à l'échelle verticale, avant même d'avoir à envisager la mise à l'échelle horizontale.
La cible toujours en mouvement
Il convient de mentionner que dans la poursuite de la performance, le goulot d'étranglement continuera toujours de bouger.
Pour un magasin Magento en stock.
Ouvrez les caches. PHP est le goulot d'étranglement
Ajouter un cache backend. PHP est le goulot d'étranglement
Ajouter un cache pleine page au niveau de l'application. PHP est le goulot d'étranglement
Ajouter un cache frontal au niveau du serveur (par exemple. Varnish). MySQL est le goulot d'étranglement
Ajouter un moteur de recherche alternatif / navigation en couches (par exemple. SOLR / Sphinx). PHP est le goulot d'étranglement
Ajouter plus de serveurs d'applications. MySQL est le goulot d'étranglement
Ajouter un esclave MySQL. Le cache frontal est le goulot d'étranglement
Ajouter plus de serveurs de cache frontal. PHP est le goulot d'étranglement
Ajouter plus de serveurs d'applications. SOLR / Sphinx est le goulot d'étranglement
Etc.
Cela devient à peu près un cas de répétition de rinçage-lavage. Mais ce qui est clair à comprendre, c'est que MySQL n'est certainement pas le premier port d'escale pour l'optimisation - et n'entre vraiment en jeu que lorsque MySQL consomme plus de CPU proportionnellement à PHP - et cela se produit UNIQUEMENT lorsque FPC et Varnish sont utilisés et le ou les serveurs traitent purement les commandes et rien d'autre (car tout le reste est dans des caches).
Ne faites pas de changements aveuglément
Le simple fait d'ajouter un esclave MySQL parce que vous nous lisez dites ci-dessus que cela aidera, peut vous coûter des performances et une fiabilité à un niveau énorme. Un réseau encombré, un serveur esclave de faible spécification ou même des paramètres incorrects peuvent entraîner des problèmes de réplication qui peuvent ralentir votre magasin au départ - ou provoquer des problèmes de synchronisation entre le maître et l'esclave.
Pour mettre les choses en perspective - quelques exemples du monde réel.
Exemple 1 - 300 commandes par heure
Nous avons utilisé le matériel suivant pour traiter 300 commandes par heure ; et seulement à ce point de basculement - nous avons alors ressenti le besoin d'ajouter un serveur MySQL dédié et un esclave MySQL local.
1
CPU de serveur : 2x Intel E5-4620
RAM: 64 Go HDD: 4x SSD 80k IOP / s
RAID: Hardware RAID 10
Version Magento: Magento EE
OS: MageStack
Pendant tout ce temps, les moyennes de charge sont restées inférieures à 3,00.
Exemple 2 - 180 commandes par heure
Il y a tout juste deux jours, un de nos nouveaux clients a facilement absorbé un gros pic de trafic. Traitement de 180 commandes par heure avec un serveur unique et Magento Community Edition .
1
CPU serveur : 2x Intel E5-4620
RAM: 64 Go HDD: 4x SSD 80k IOP / s
RAID: RAID matériel 10
Version Magento: Magento CE
OS: MageStack
Site Web: Wellgosh.com
Pendant tout ce temps, les moyennes de charge sont restées inférieures à 6,00. La charge était plus élevée dans ce scénario et cela était dû à quelques facteurs.
- Aucun réglage côté magasin n'a été effectué comme dans l'exemple 1
- L'absence d'un FPC au niveau de l'application
Et compte tenu de la récence de cela, nous avons toujours les statistiques détaillées pour donner quelques commentaires au moyen de graphiques. Ceux-ci racontent une excellente histoire de la répartition de la charge entre les composants clés d'une architecture Magento séparée (équilibreur de charge, serveur Web, serveur de base de données, etc. - à l' aide de MageStack ).
Donc d'avant en arrière ... la date que vous voulez regarder est à 22h00 le 22 février.
Paquets de pare-feu
Trafic des vernis
Trafic Nginx
Charge MySQL
Charge CPU
Et surtout, la répartition de la charge
Cette image raconte vraiment tout. Et c'est que MySQL n'est certainement pas un fardeau - pas encore au moins. Donc, notre conseil, concentrez vos préoccupations de performance ailleurs, à moins que vous ne traitiez plus de quelques milliers de commandes par heure.
Et en résumé
Apporter des modifications aux performances n'est pas une solution unique. Il s'agit d'analyser vos goulots d'étranglement actuels et d'apporter des modifications / ajustements subtils en fonction de votre magasin et de votre infrastructure.
Mais à part les performances, il y a d'autres avantages à utiliser Percona
Nous utilisons Percona XtraDB, presque exclusivement. Nous exécutons des versions compilées sur mesure de MySQL que nous avons développées spécifiquement pour Magento et avions consulté Percona pendant le processus. Mais ce n'est pas seulement la performance qui a influencé ce choix.
- La boîte à outils Percona
- pt-query-digest
- xtrabackup
- etc.
- Fréquence de libération de Percona
- Assistance consultative Percona
- Cache chaud redémarre avec la préservation de la piscine InnoDB
Et beaucoup plus. Donc, l'utiliser sur MySQL avait d'autres avantages que les performances. En fait - MySQL est et a toujours été le moindre de nos soucis dans la recherche de performances et de stabilité.
Attributions: wellgosh.com , sonassi.com , iebmedia.com .