Performances Lighttpd pour du contenu statique
Lighttpd
On peut séparer le problème en deux:
- Les ressources "statiques", donc de simple fichiers: ceci est simple à dimensionner et très prévisible. Un benchmarking peut donc donner de très bons chiffres pour estimer des besoins de production.
- Les ressources "dynamiques": ceci est nettement plus complexe et dépend entièrement de l'application et la technologie utilisée (Ruby, PHP, Perl, etc.).
Ce billet se concentre sur la première partie. Et sur lighttpd, que nous utilisons actuellement pour ce type de charge. J'espère pouvoir faire suivre avec un benchmark équivalent sur Apache, qui n'a rien à envier d'un Lighttpd ou d'un Nginx.
Configuration
Le benchmark a été effectué sur deux serveurs distincts, reliés via leurs interfaces GbE et un switch adapté. Pour être plus précis l'ensemble est situé sur des lames Dell d'un chassis PE1955, dans des serveurs virtuels Xen.
Le serveur cible est un serveur de production qui n'était pas sollicité. Ceci nous donne donc une très bonne idée de la capacité réelle du serveur. Il possède l'équivalent d'un coeur de Xeon L5310 (1.6GHz) et suffisamment de RAM pour que ce paramètre ne rentre pas en ligne de compte. Les I/O disques n'ont pas été sollicitées.
Un gros fichier "creux" big.txt (sparse file) de 10GB a été généré:
dd if=/dev/zero of=big.txt bs=1024 count=1 seek=$((10*1024*1024))
Un script basé sur le très simple et très efficace Apache Bench simule la charge équivalent de N téléchargements concurrents du fichier bigfile.txt selon le schéma suivant:
- 5min de téléchargement depuis 10 clients concurrents
- 5min d'inactivité
- 5min de téléchargement depuis 100 clients concurrents
- 5min d'inactivité
- 5min de téléchargement depuis 1000 clients concurrents
Pendant ce temps des mesures très simples sont récupérées sur le serveur. Vous trouverez l'ensemble des scripts utilisés, ainsi que les résultas sur notre forge.
Résultats
Le graphe suivant montre la mémoire totale utilisée sur le serveur (en octets). Ceci compte donc à la fois la consommation de Lighttpd et celle du noyau pour maintenir les sessions TCP. La courbe rouge montre la charge du serveur (moyenne exponentielle sur 5min).
Lighttpd a été démarré juste avant le test, il n'avait reçu aucune requête avant de recevoir la première charge. On observe d'ailleurs un régime transitoire curieux sur les deux premières minutes qui est peut être lié à ceci. J'ai choisi de l'ignorer car on ne le retrouve pas sur les charges suivantes, et le cas de 10 connexions simultanés n'est probablement pas emblématique de l'ordre d'échelle que je voulais tester (100 et 1000).
A noter que le nombre de connexions a été mesuré mais non graphé: lors du déclenchement de la charge, le nombre de connexions atteignait instantanément la quantité voulue, et restait parfaitement constant jusqu'à l'arrêt de la charge.
Pendant chaque test de charge, le traffic sortant brut du serveur web était de 105 MB/s en moyenne. On peut considérer que l'interface réseau du serveur était saturée et que le facteur limitant était bien cette dernière (ou du moins l'ensemble interfaces + switch). C'est un résultat attendu pour une infrastructure GbE (sans jumbo frames).
Interprétation
Le plus surprenant est la consommation de mémoire non proportionnelle aux nombre de connexions. On lit empiriquement: +6200kB pour 100 connexions, puis +28000kB pour 1000 connexions. Il semble raisonnable de supposer qu'elle est vraiment linéaire, mais que Lighttpd (et/ou Linux) pré-allouent des structures de données. Dans ce cas on peut estimer un coût global de 24kB par connexion supplémentaire ((28000 - 6200) / 900). Je serais satisfait de cette hypothèse quand je l'aurai vérifiée pour 10,000 connexions simultanées.
Il y a également une légère croissance de la consommation mémoire pendant le régime stable de la charge. Comme il s'agit d'une mesure globale (noyau, serveur web, etc), rien de conclusif. Il serait probablement intéressant de lancer la charge pendant 24h.
On voit également un effet d'hystérésis, la consommation mémoire ne revenant pas à son seuil initial en fin de charge. Ceci me semble parfaitement normal (et typique de structures de réutilisation comme les SLAB).
Dernière note sur la charge: j'ai observé qu'elle était entièrement dû à l'utilisation du CPU (35% d'utilisation CPU par Linux, virtuellement 0 côté userspace). Bien entendu, uniquement des I/O réseau, le fichier big.txt ne contenant réellement qu'une page de donnée. Peut être que ce CPU serait insuffisant pour une interface réseau 10GbE, mais Xen a probablement un overhead non négligeable sur ces charges extrêmes.
Conclusion
Pour servir 1Gbbps de données statiques, il ne faut dans le cas général pas grand chose:
- Un serveur d'entrée avec un CPU minimaliste
- Une interface réseau GbE robuste et bien testée (e1000, tg3, etc)
- Un jeu de données utiles (working set) qui rentre dans votre RAM: préférez acheter 64GB de RAM si c'est nécessaire plutôt que d'investir dans une infrastructure de stockage hors-norme, vous obtiendrez probablement un retour efficacité/prix sans commune mesure.
