Ces derniers temps j’ai vu passer des cahiers des charges assez loufoque niveau dimensionnement de serveur. Pour un même CMS en PHP j’ai vu des infras basées sur des serveurs à base de 1/6e de CPUs et des clusters de 4 à 6 serveurs 16 coeurs, chacun pour une audience similaire (1 à 10 millions de pages vues/mois).
En général je fais quelques produits en croix sur un coin de nappe pour voir si au moins les ordres de grandeur sont corrects. Dans les deux cas les specs techniques étaient absurdes, mais quand on veut avoir du répondant il vaut mieux aussi fournir les bons chiffres. Du coup j’ai formalisé mes calculs qui relèvent pourtant de la tambouille dans une feuille de calcul presque rationnelle que je partage ici : lamp-sizing.ods.
Exemple très rapide : 1M PV/mois sur un site actif 20 jour/mois et 8h/jour, avec 0.5sec CPU par page et 1 requête AJAX/page en moyenne donne :
- 3,5 req/sec en moyenne; besoin en CPUs: 2
- 17 req/sec avec un ratio de sécurité de 5x; besoins en CPUs: 9
L’adminsys avisé retient l’ordre de grandeur et se dit qu’il devrait pouvoir démarrer avec 2 CPUs mais qu’il a intérêt à pouvoir monter jusqu’à 8 facilement. Si c’est une migration et que le trafic est déjà soutenu, alors on ne prend aucun risque et on prend 8 CPUs, voire plus.
Tous ces calculs supposent quelques hypothèses et approximations qui sont documentées dans la seconde feuille du document LibreOffice, je les reporte sur ce blog pour qu’ils soient plus facile à retrouver et consulter.
Edit : j’ai rajouté un paragraphe mentionnant que les caches nétaient pas pris en compte et ce qu’on pouvait attendre d’eux. Personne ne se passe de cache, et la feuille de calcul ne les prend pas en compte.
Cette feuille de calcul permet d’obtenir des ordres de grandeur pour le dimensionnement d’une plateforme LAMP. Les résultats sont grossiers et incomplets, il est en particulier quasiment impossible d’obtenir des résultats exploitables pour la partie SQL, la nature des requêtes étant bien plus importante que leur débit. Mais elle permet d’obtenir des ordres de grandeur réalistes. Il suffit d’appliquer le facteur multiplicteur de sécurité qui convient selon son expérience et ses exigences de performance.
Le modèle considère que seules les requêtes dynamiques interviennent dans le dimensionnement (celles servies par PHP, Ruby, Python, etc). Les fichiers statiques sont en général faciles à gérer en larges volumes et débits et peuvent être facilement traités par un CDN si nécessaire (S3, Akamai, etc).
Une page vue est constituée d’une requête HTTP dynamique pour fournir la page HTML ainsi que 0, 1 ou plusieurs requêtes AJAX associées.
Le coût de rendu d’une requête HTML ou AJAX est considéré identique et principalement imputé en temps CPU (celui nécessaire pour exécuter le code de l’application). Le dimensionnement SQL relevant d’avantage de problème d’I/O et de locking, il n’est pas abordé.
Coûts constatés :
- WordPress : 0,25 à 1 seconde CPU par page, 0 à 2 requêtes AJAX par page, 10 à 100 requêtes SQL par page
- Drupal : 0,1 à 0,8 seconde CPU par page, 0 à 1 requête AJAX par page, 5 à 100 requêtes SQL par page
Les chiffres sont évaluées sur une moyenne - un trafic moyenné sur une période “active”. Plus la période active est courte, plus le trafic moyen est élevé (à trafic en PV/mois constant). Sur un intranet, on peut par exemple compter les jours ouvrés (environ 20/mois) et les heures de bureau (environ 8h/jour). Un site public a en général une période active plus large.
Le dimensionnement complet d’un serveur frontal PHP peut se baser sur le modèle suivant :
- 1GB de RAM pour 1 CPU
- 2 processus PHP par CPU avec memory_limit = 256 MB
Ceci permettant dans le cas de charge maximale un ralentissement de 50% des temps de réponse et une utilisation de la moitié de la RAM disponible (le reste étant potentiellement utile pour les caches internes - kernel - ou externes - memcached, Redis, etc). Ne sont pas pris en compte les tâches de fond dont le contexte est différent (besoin de beaucoup plus de RAM et CPU, appels ponctuels) et peuvent être résolus à part.
Note : les mécanismes de cache ne sont pas pris en compte. Sur des sites où le contenu est facilement cachable (ceux orientés contenu où la majorité des internautes est “anonyme”), il est raisonnable de considérer que l’on peut gagner un ordre de grandeur en besoin CPU. En d’autre termes si la feuille de calcul vous recommande 20 CPUs en moyenne, avec un cache vous devriez retomber sur un besoin équivalent à 2 CPUs environ. C’est typiquement ce qu’on peut observer sur un magazine, un blog, etc.
Leave a comment