Nous travaillons actuellement avec une exigence selon laquelle la première réponse du serveur Web doit être inférieure à 200 ms au Royaume-Uni. Actuellement, sous 2 serveurs Web dédiés sous équilibreur de charge et 1 serveur de base de données, nous entrons à 800 ms.

Le site à l'heure actuelle a moins de 5 clients, 2 produits, 4 catégories, il n'y a pas de frontend sur le site pour le moment, il est sans style et sans image.

Il est également exécuté sur nginx avec Varnish.

Quelqu'un peut-il me donner des conseils sur les configurations de serveur Web? Pourquoi les nôtres entrent-ils lentement? Que pouvez-vous recommander pour optimiser cela? Besoin d'être 400% plus rapide!

Je vais mordre.

Cette première réponse du serveur Web doit être inférieure à 200 ms au Royaume-Uni.
Il n'y a pas de front-end sur le site pour le moment, il est sans style et sans image.

Vous n'atteindrez pas ces chiffres sans l'aide de Varnish ou de FPC (ou des deux). J'espère certainement que ce chiffre ne doit pas également inclure du contenu statique (chaque fois que vous décidez de l'ajouter), car il est presque impossible à réaliser (à moins d'avoir peu ou pas d'images / js / css).

Nous arrivons à 800ms.
Il est également utilisé sur Nginx avec Varnish

Vous avez mal configuré Varnish.

Une installation correctement configurée de Varnish générera des temps de chargement de page inférieurs à 100 ms (nous nous en approchons à moins de 10 ms).

En fait, pour Magento, vous devriez vous attendre à quelque chose comme ça,

Lorsqu'un client n'est pas connecté ...
c'est-à-dire. Ne pas avoir créé une session unique (ajout au panier / liste de souhaits, connexion, etc.)

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

Lorsqu'un client est connecté ...
c'est-à-dire. Après avoir créé une session unique (connecté, articles dans le panier, etc.). À ce stade, Varnish sera probablement désactivé. Et si vous avez choisi d'utiliser les ESI (en fonction des appels inversés), il peut conserver un temps de chargement de page similaire à celui du cache FPC (en raison des frais de démarrage), ou bien augmenter les temps de chargement des pages au-delà de la mise en cache.

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

Ce n'est pas un cas de réglage de Varnish - c'est un cas de - "vous ne cachez rien du tout" .

Les fichiers de configuration du serveur Magento idéal

Il n'y en a pas, eh bien, pas tout à fait.

Nous exploitons plus de 400 serveurs, tous purement des magasins Magento - de tailles et de capacités variables. Et il est rare que les fichiers de configuration que nous avons sur l'un correspondent à ceux d'un autre. C'est parce que toutes les entreprises ne se ressemblent pas.

Les goulots d'étranglement peuvent se former pour différentes raisons:

1. Nombre élevé de visiteurs simultanés, avec sessions actives
2. Victimes de «mauvais» robots d'exploration, générant une charge nécessaire et inestimable
3. Forte proportion de hits de navigation en couches
4. Nombre élevé de requêtes de recherche
5. Volume élevé de transactions par heure
6. Modèle mal construit
7. Trop nombreuses / lentes / volumineuses extensions tierces
8. Liens entrants obsolètes menant à une forte proportion de 404 hits
9. Capacité d'interface réseau à la limite
10. Grand catalogue / complexe (beaucoup de produits / catégories / attributs)

Donc, avec tous les magasins de ce spectre, chacun a une approche différente pour des performances optimales.

Pour résoudre les problèmes décrits ci-dessus; nous éviterons délibérément de simplement dire "plus / meilleur matériel"

1. Utilisez un FPC au-delà de celui de Varnish
2. Filtrez / bloquez les robots malveillants à la périphérie du réseau - ou redirigez toutes les demandes vers Varnish quel que soit l'état du cookie / l'URL
3. Changez la navigation stockée en couches en SOLR, en fonction des filtres de navigation stratifiés
4. Changer la recherche d'actions en SOLR
5. Répartissez la charge MySQL sur la configuration maître / esclave - ne le faites que si vous avez la garantie que la charge de navigation est absorbée par Varnish / FPC
6. Reconstruire le modèle
7. Dépouille-les
8. Surveillez les journaux d'accès en permanence et réécrivez les URL chez Nginx / Varnish avant la livraison. Si vous le faites au niveau Nginx, assurez-vous que Varnish met en cache les redirections 301/302.
9. Diviser le contenu statique en CDN ou améliorer la connectivité
10. Ajouter plus de matériel (enfin, nous devions le dire à un moment donné)

Donc, dans cet esprit, vous verrez qu'il ne sera probablement pas un fichier de configuration Nginx, un fichier de configuration PHP fcgi pool, un fichier de configuration MySQL ou un fichier de configuration Varnish qui seront identiques. Coupler cela avec le matériel change tout seul; mémoire disponible, performances d'E / S (disque dur et réseau) et processeur - et vous découvrirez que de subtiles variations conduisent au gain de performances de 400% que vous souhaitez - mais vous ne trouverez pas de réponse rapide en ligne.

Vous pouvez copier + coller le livre blanc sur Peformance parrainé par Peer 1 (nous ne le recommanderions pas); espérons que les paramètres ne dépasseront pas la mémoire disponible, les limites de threads, les états TCP / IP, la capacité d'E / S et entraîneront des performances inférieures à celles d'une configuration Apache / mod_php vanille.

Alors continuons.

La pile de serveurs Magento idéale

Ceci est plus susceptible de vous rapprocher de la réalité. Un bon exemple pour illustrer cela consiste à montrer comment un système d’exploitation Magento dédié est configuré, MageStack.

Prenez les sous-composants séparés et vous obtenez une liste des logiciels les plus optimaux / critiques, lorsqu'ils sont configurés correctement , pour exécuter un magasin Magento. Notamment:

Pare-feu, filtre DOS, équilibreur de charge, vernis, Nginx, PHP, Redis, Memcached, MySQL

Alors, quand vous demandez:

Quelle est la meilleure configuration du serveur Magento?

Quel est votre but exactement?

1. La haute disponibilité
2. Fiabilité
3. Simplicité d'administration
4. Performance
5. L'évolutivité

Assez de conférences, comment ferions-nous

Pour refléter partiellement la réponse donnée sur l'erreur du serveur dans une veine similaire. Vous avez 3 serveurs à votre disposition - commencez par les orienter de la manière la plus optimale possible. Nous éviterons une solution hautement disponible car elle dépasse de loin le cadre de cette réponse.

Les sous-composants requis pour une configuration multi-serveur sont:

• Pare-feu
• Equilibreur de charge
• Serveur Web
• Serveur MySQL
• Stockage commun

Nous allons donc utiliser plusieurs des systèmes. La conformité PCI-DSS dicte un rôle pour chaque serveur. Donc, avec 5 rôles et 3 serveurs - vous serez immédiatement en infraction. MageStack contourne cela en utilisant la virtualisation - vous pouvez faire la même chose.

Serveur 1: Equilibreur de charge + serveur Web
Serveur 2: Serveur Web
Serveur 3: Serveur de base de données

Sans faible temps de latence et bande passante réseau importante (> 1 Gbps, <125µs), plutôt que de disposer d'un stockage commun, il est préférable de simplement stocker le répertoire racine du magasin sur chaque machine et de répliquer les données, en temps réel ionotifyou inutilisé. un crontravail. Encore une fois, nous éviterons les systèmes de fichiers réseau tels que NFS ou les périphériques de blocs répliqués tels que Gluster ou DRBD, car une configuration étendue et une bande passante réseau décente sont nécessaires.

Le vernis doit s’asseoir le plus près possible de l’avant. Mais Varnish ne peut pas déchiffrer SSL. Alors combinez-le avec un terminateur SSL; Nginx, Pound, Stunnel, Stud, etc. L'équilibreur de charge intégré dans Varnish n'est pas formidable - mais conviendrait pour une configuration à 2 serveurs.

Nginx + PHP-FPM c'est bien, mais ne buvez pas trop du kool-aid de Nginx. Il fonctionnera presque de la même manière qu’une configuration Apache / mod_php traditionnelle. Voici quelques informations utiles sur la nécessité de ne pas utiliser Nginx . Nginx est bon, très bon en fait, mais ce n'est certainement pas un goulot d'étranglement pour un magasin Magento - et étant donné sa complexité et le manque de support natif de Magento. La plupart des administrateurs système novices auraient intérêt à utiliser Apache / mod_php avant tout. Cela peut sembler une recommandation archaïque sur l'utilisation de PHP-FPM - mais nos tests de performance ont montré que les performances sont seulement environ 7% plus rapides avec la solution Nginx - lorsqu'elles sont correctement configurées.. Le réglage et l'expérience requis pour une configuration Nginx / PHP-FPM fiable et hautes performances sont assez vastes pour lui permettre de surpasser Apache / mod_php. Quel que soit votre choix, c'est votre appel.

Le serveur de base de données est simple, MySQL. Mais comme mentionné précédemment, si vous avez un site de conversion élevé, une configuration maître / esclave est conseillée. Vous pouvez déterminer si vous devez suivre cette approche en lisant cet article .

Ensuite, vos caches d’arrière-plan périphériques, Memcached et Redis. Sur les plus petits magasins, le stockage de sessions dans une instance Memcache et le cache d’arrière-plan rapide dans une autre apporteront de bonnes performances. Nous ne recommandons pas de stocker les balises de cache dans un backend lent, car cela pose plus de problèmes qu'il n'en génère. Donc, avec une configuration Memcached, vous devrez supprimer le balisage en cache . Au lieu de cela, nous utilisons une configuration comme celle-ci .

Redis n’est pas natif de Magento, mais avec l’extension de Colin Mollenhour - une meilleure solution que Memcache, supporte les balises de cache, le stockage de session et même le stockage de cache persistant - ce n’est pas aussi volatile que Memcache . Mais il a ses inconvénients. Nous avons constaté dans les magasins de production à grande échelle (> 500 commandes / heure,> 30k uniques / heure) que le cache (et les balises) peuvent se remplir très rapidement et qu'une fois le point de saturation atteint, le mécanisme LRU échoue quelque peu ( malgré des réglages différents) et provoque un goulot d'étranglement immédiat énorme. Il est donc prudent d'élaguer régulièrement les anciens enregistrements manuellement.

Alors, quel matériel doit être utilisé pour quoi?

Serveurs Web: processeur le plus rapide, la plupart des cœurs de processeur, ratio de 2 Go de RAM /
serveur de base de données DB: processeur rapide, entrée / sortie de disque la plus rapide, plus de RAM

Ainsi, lorsque vous utilisez plusieurs machines sur trois, la meilleure disposition serait:

Serveur 1: Terminateur SSL -> Varnish -> Nginx / Apache>
Serveur PHP 2: Nginx / Apache> PHP, Redis, (Esclave MySQL)
Serveur 3: MySQL

Quant à la configuration spécifique de chaque application. Eh bien, cela dépend des spécifications de votre matériel, de la complexité de votre magasin, de votre type et de la nature du visiteur et du volume considérable de visiteurs.

Vous êtes sur une bonne voie avec cette configuration de cluster. Je recommande d'ajouter un hôte de cache dédié pour Redis; sélectionnez-en un avec une puissance de calcul élevée et beaucoup de RAM (~ 64 Go).

Voici la liste complète des configurations que j'ai utilisées pour un cluster LEMP à haute disponibilité, à tolérance de panne, réparti et à charge équilibrée. Il inclut app/etc/local.xmlla core_config_datatable et les configurations pour MySQL, php-fpm, nginx et Redis. Tous exécutent Ubuntu 12.04 LTS 64 bits. Les configurations incluent de nombreuses optimisations sans inconvénient.

Points forts

• Utilisateurs administrateurs: 46
• Catégories: 2 450 (le plus important compte 2 400 produits)
• Entités de produit: 101 000
• Produits Combo: 484
• Relation produit: 54 000
• Produits configurables en stock et activés: 10 100
• Blocs CMS: 3 100
• Pages CMS: 1 400

Août 2013 trafic:

• 40 millions de pages vues par mois
• 2,3 millions de visiteurs uniques
• 46 000 départs mensuels
• 89% des visiteurs américains

Hébergeur

Il y a 10 hôtes derrière des pare-feu matériels et des équilibreurs de charge matérielle redondants et hautement disponibles. La plupart des actifs statiques sont déchargés sur un CDN.

• temps de réponse moyen sur l'ensemble du site: 282 ms
• Réponse FPC moyenne: 48 ms
• charge moyenne: 0,6 à 1,0 (lors des tests, les performances se dégradent de 35% lorsque la charge moyenne atteint ~ 5,0)
• Deux processeurs Intel Xeon E3-1230 V2 à 3,30 GHz (4 cœurs chacun)
• 32 Go de RAM DDR3 1333 MHz

Modules

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

Hôtes cache

Deux hôtes exécutent Redis dans une configuration maître-esclave avec basculement automatique. Trois instances Redis (sessions, backend et FPC) sont utilisées pour augmenter le débit et fournir un réglage précis des comportements de persistance.

• 3000 commandes par seconde
• Temps de réponse moyen de 0,7 ms
• charge moyenne de 1,0 à 1,5
• Processeur Quad Intel Xeon E5-2620 0 à 2,00 GHz (6 cœurs chacun)
• 128 Go de RAM DDR3 1333 MHz avec mémoire tampon
• Disques mécaniques, RAID 1, contrôleur matériel

Hôtes de base de données

Deux hôtes exécutent MySQL 5.6.11 dans une configuration maître-esclave avec basculement à chaud.

• 1500 commandes par seconde
• Temps de réponse moyen de 1,1 ms
• charge moyenne de 0.1 (maître) et 0.4 (esclave)
• Processeur Quad Intel Xeon E7-260 à 2,27 GHz (10 cœurs chacun)
• 128 Go de RAM DDR3 1333 MHz avec mémoire tampon
• SSD, RAID 1 + 0, contrôleur matériel
• MySQL 5.6.11 avec tcmalloc

Une autre astuce serveur indispensable pour Magento est d’installer PHP 5.4 ou 5.5 avec OPcache . PHP 5.4 est beaucoup plus rapide que la version 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Je souhaite ajouter un autre conseil important qui améliore la vitesse de page de Magento lorsqu'il n'est pas mis en cache par vernis et qu'il n'est pas activé par défaut (le temps de chargement de la page de panier est passé de 6sc à 1.5sc).

Activer le cache de requête mysql dans /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

le type de cache le permettent, la taille du cache est la valeur utilisée par le cache en mémoire et la limite du cache est la taille maximale du résultat de la requête à mettre en cache

Avec notre configuration actuelle, nous recevons la réponse initiale en 400 ms et le document complet en 2 secondes (avec une connexion standard de 5 Mbps). La taille de notre page d'accueil est de 1mb.

Notre configuration est basée sur AWS comme suit: Nous avons une instance ec2 avec un équilibreur de charge connecté à une base de données RDS (avec basculement). Nous avons également mis en œuvre un cache de page complet avec un backend de cache redis pour le stockage en cache et le stockage de session.

En moyenne, nous avons 300 à 400 visiteurs par jour, mais grâce à la mise en cache redis, nous avons eu une utilisation minimale des ressources ec2 tout en maintenant la vitesse et en réduisant les coûts.

La raison pour laquelle nous avons un équilibreur de charge est que ec2 est configuré pour démarrer automatiquement une nouvelle instance si, dans de rares cas, nous avons des pics de trafic que la configuration actuelle ne peut pas gérer.