Expérience du monde réel dans les performances de mise à l'échelle et de réglage

Le site Web sur lequel je travaille devrait avoir un taux de réussite énorme peu après son lancement . Le client parle de la possibilité d’environ 2500 visites par seconde pendant environ un jour.

Ignorant le fait que ce taux de réussite est probablement l'optimisme sauvage et que, mis à part l'obtention des serveurs les plus grands possibles, quelle est la meilleure façon de configurer Drupal pour prendre en charge un taux de réussite élevé.

J'ai lu Mise à l'échelle de l' infrastructure drupal.org , du blog sur la performance Drupal , des meilleures pratiques pour la mise à l'échelle de Drupal et de nombreuses autres pages, mais ce que je recherche, c'est une expérience réelle de ce type de fonctionnement: ce qui fonctionne, ce qui ne fonctionne pas et ce qu'il faut faire. attendre.

La réponse de Markdorison est essentiellement la méthode acceptée pour s'attaquer à ce problème. Je vais aller un peu plus loin.

Lorsque vous avez Pressflow pour D6 ou Drupal pour D7, Memcached et Varnish fonctionnent parfaitement ensemble, vous devez personnaliser le code de votre fichier VCL . Il y en a des gratuits qui font des points de départ mais vous devez toujours jouer avec eux.

Pour que Varnish fonctionne de manière optimale, assurez-vous de le démarrer avec -s malloc xG plutôt qu'avec le fichier par défaut -s fichier / chemin / vers / fichier. Également avec Varnish, cachez les éléments statiques de Varnish aussi longtemps que vous le pouvez.

Si vous avez plusieurs serveurs Web, supprimez l'ETag de l'en-tête envoyé à Varnish dans VCL. Je supprime également Expires et je fais simplement confiance à Age et à max-age dans les en-têtes afin que les navigateurs soient de nouveau accessibles.

La version 1.5 (au 3 mars 2011) est toujours la version la plus rapide du module Memcached de Drupal.org. Je le déploie généralement en utilisant un seul bac par serveur pour réduire le trafic TCP pour les connexions à plusieurs bacs à grande échelle)

Configurez la mise en cache dans "Performances" sur externe et définissez un âge maximum qui enverra les en-têtes appropriés à un proxy de mise en cache tel que Varnish.

Si vous ne parvenez pas à mettre certaines pages en cache correctement dans Varnish, consultez les articles de blog sur le Web qui expliquent comment inspecter les demandes. Voici un exemple de message que j'ai écrit il y a quelque temps: Qu'est-ce qui empêche Varnish et Drupal Pressflow de mettre en cache des pages anonymes d'utilisateurs anonymes?

Vous devriez choisir InnoDB (ou l’un des autres noms d’autres fournisseurs comme XtraDB) pour MySQL et y déplacer toutes les tables. Ensuite, consultez ce billet de blog pour obtenir des conseils de réglage de base http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Avoir un pool de réserve important est fondamentalement important. Lors du test de charge du site, activez le journal de requête lent. Vous voudrez probablement d’abord capturer les requêtes d’une durée supérieure à 50 ms, puis les ajuster et réduire de manière répétitive le temps de capture de journal lent jusqu’à ce que la plupart des requêtes soient exécutées avec des index et s’exécutent assez rapidement.

D'autres bases impliquent d'avoir APC dans PHP. Si vous choisissez CGI rapide plutôt que mod_php, essayez de faire en sorte que le cache APC soit partagé entre les instances php en configurant un bon script wrapper. Assurez-vous également que le cache APC se trouve dans un fichier mappé en mémoire pour extraire chaque dernier bit de PHP.

Je recommanderais de commencer par Pressflow (si vous utilisez Drupal 6), Memcache , Varnish et une forme de réseau de distribution de contenu (CDN) telle qu'Akamai. Le résultat final devrait être le moins possible d'utilisateurs de ce type qui frappent réellement votre serveur d'origine.

Si vous avez des parties de la page que vous ne pouvez pas mettre en cache pour des utilisateurs non anonymes (éléments propres à cet utilisateur, "Welcome userX", etc.), vous pouvez explorer des options permettant de renseigner ces éléments de la page, telles que les opérations asynchrones. rappels ou côté bord comprend.

Si vous avez un groupe d'utilisateurs internes plus restreint (un groupe d'éditeurs, par exemple) qui doit pouvoir afficher une version non mise en cache du site, nous vous recommandons d'exposer une version non mise en cache de votre site à une autre URL (protégée derrière un réseau privé virtuel). ou équivalent si possible).

2500 visites par seconde sur une journée - si par "hit" vous voulez dire "page livrée", vous obtenez 216 millions de pages par jour. Laissez-moi vous dire ceci: vous n’avez pas 216 millions de pages par jour. J'aime ces clients ...

Cela dit, une donnée de trafic brute ne dit rien. Bien que le conseil dans ce fil soit clair sur Varnish / CDN si tout ce que vous avez est du trafic anonyme, mais si vous êtes connecté au trafic, vous faites face à un défi. Mais avant de consacrer un temps et des efforts impies à la résolution d'un problème, assurez-vous que vous en avez un. 2500 hits par seconde, Bing obtient moins que cela, vous vous en rendez compte, non?

• Du côté serveur

  • Installez Varnish pour la mise en cache des pages pour les utilisateurs anonymes.
  • Installez un système de cache persistant (Memcached, APC, Memcache).
  • Utilisez un CDN tel que Akamai pour gérer des fichiers statiques (JavaScript, CSS, images).

• Côté code

  • Utilisez Pressflow, il permet à Varnish de servir une page en cache à des utilisateurs anonymes.
  • Nettoyez la table de surveillance de Drupal. Chaque fois qu'une erreur de chien de garde est consignée, elle consomme des ressources de la CPU sur le serveur Web et le serveur de base de données. Cela augmente également considérablement le temps de chargement.
  • Implémentez des stratégies de cache statique et persistant jusqu'à ce que le journal de requête lent apparaisse propre.
  • Évitez à tout prix les erreurs PHP qui surviennent dans les boucles foreach imbriquées.
  • Désinstallez les modules inutilisés.
  • Activez la mise en cache pour les blocs principaux et les vues Drupal.

• Base de données

  • Assurez-vous que les tables sont correctement indexées pour une recherche plus rapide.
  • Ne stockez pas les enregistrements inutiles, l'accès à une base de données de 100 nœuds sera toujours plus rapide qu'une base de données de 3 millions de nœuds.

J'écouterais également ce podcast Lullabot sur la manière dont ils ont configuré le site Web Grammys.com pour une explosion du trafic au cours d'une semaine. C'était une jolie explication pédagogique.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Bien qu'il soit très difficile de prévoir les tendances, si vous avez une idée juste des niveaux de trafic. Charger en charge votre solution. Il existe une foule d'options différentes et il ne sera pas possible de prédire beaucoup tant que le trafic en direct ne sera pas activé, mais si vous chargez autant de tests que possible, vous aurez au moins une certaine confiance dans le fait que votre configuration peut gérer le trafic.

Tous les réglages dans le monde ne vous aideront pas si vous ne le testez pas d’abord.

Il s’agissait d’une présentation à DC SF sur la façon dont l’économiste a procédé. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder

Pour les sites Web à fort trafic, vous devez utiliser plusieurs serveurs et équilibreurs de charge ou utiliser simplement CDN. Il est également très important de mettre en cache autant que possible afin de minimiser la charge sur les serveurs Web.

L'utilisation de Content Delivery Network ( CDN ) permet de répartir les ressources sur plusieurs domaines (partage de domaine), ce qui réduit la charge sur le serveur Web.

L'utilisation de CDN aide à la mise en cache distribuée et à l'accélération à distance, et contribue également à atténuer les attaques par DDoS , en raison de plusieurs points d'extrémité. Cela contribue à la sécurité, car le contenu en cache est plus difficile à exploiter.

Exemples de fournisseurs: Fastly , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Voici quelques suggestions supplémentaires:

• Avec CDN, utilisez des domaines sans cookie pour que les composants statiques soient mis en cache (comme sstatic.net ). Certains mandataires pouvant refuser de mettre en cache les composants demandés avec les cookies.
• Réchauffez vos caches après avoir effacé ceux-ci (à l'aide de wget, Cache Warmer , Drush ECL ).
• Utilisez la surveillance des performances (par exemple New Relic ou Yottaa qui ont une intégration pour Drupal).
• Utilisez l'outil de surveillance pour votre site Web (par exemple, Nagios).
• Installez le module d'intégration de Varnish et Varnish HTTP Accelerator , puis configurez-le .
• Varnish + Authcache: Cochez cet exemple de VCL pour le fichier de configuration Authcache Varnish.
• Pensez à Pound ou à NGINX devant le vernis. Voir: Pourquoi Pound est génial devant Varnish .
• NGINX peut fonctionner en proxy inverse et en équilibreur de charge, afin de remplacer Pound and Varnish.
• Considérez une version commerciale de Varnish ou NGINX pour utiliser des fonctionnalités non disponibles dans la version open source "community".
• Envisagez l'équilibrage de charge / la mise en cache matérielle pour remplacer Varnish et Pound (par exemple, BIG-IP F5 ).
• Utilisez des outils tels que abJMeter for TTFB , des tests de charge et de contrainte sur votre application Web.

Ainsi, votre architecture Web du point de vue de l'utilisateur peut ressembler à:

1. Utilisateur (mise en cache du navigateur local).
2. NGINX ou Pound + Varnish (équilibreur de charge, proxy inverse en tant qu'accélérateur HTTP).
3. Apache (serveur Web).
4. PHP-FPM (gestionnaire de processus PHP FastCGI).
5. MariaDB (base de données).

Pour obtenir des suggestions d'optimisation Drupal, vérifiez: Comment améliorer les performances de Drupal?

Activer deux extensions:

• Zend OPcache
• wincache

Votre performance fonctionnera mieux.

Si vous souhaitez utiliser Zend OPcache et Wincache dans Microsoft Azure, créez d’abord un nom de dossier " ini" dans " D:\home\site\". Créez également 2 fichiers, ' .user.ini' et ' settings.ini'

Ajoutez la configuration suivante dans chaque fichier:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Ajoutez également un paramètre d’application à votre application Web avec la clé PHP_INI_SCAN_DIR et la valeur. d:\home\site\ini

Après avoir modifié PHP_INI_SYSTEM, redémarrez votre application Web. Si vous voulez en savoir plus sur la configuration de twigging, veuillez consulter la documentation de Microsoft .

Après le réglage ci-dessus, mon site Drupal (Drupal 8.3) se charge en moins de 3 secondes.

Vous pouvez également envisager de redistribuer la charge sur plusieurs serveurs à l'aide d'une solution d'équilibrage de charge logicielle / matérielle basée sur DNS. Cela permettrait également de gagner en tolérance de panne.