Le 21/01/2013 16:28, Wallace a écrit :
Le 21/01/2013 16:20, Julien Escario a écrit :
Tiens, je digresse : tu utilises quoi pour faire des tests de charge aussi importants ?
- AB, boucle de wget pour faire du test de base et du debug sur
certaines urls
- Tsung pour faire des scénarios de visiteurs ou rejouer une plage de
temps de surf normal de la plate-forme actuellement en prod
- un autre outils que j'ai pas utilisé depuis un bout de temps mais qui
est génial, tu enregistres une session surf dans FF et il te sort le code Perl qui correspond. Après tu peux le rejouer, modifier, paralléliser. Je l'utilisais à une époque pour la supervision applicative avancée mais je suis passé sur des librairies persos en PHP à présent.
SIEGE / SPROXY ? Tsung est en attente de test depuis plusieurs semaines ;-) Faut que je trouve un peu de temps.
Mon soucis était plutôt de générer des requêtes semblant venir de plein d'IPs différentes mais je dois pouvoir bricoler ça avec un peu de shell, la RFC1918 et mes routeurs.
L'hébergement web performant c'est intervenir sur toutes les couches, le réseau wan, le réseau lan, les serveurs, les systèmes, les serveurs applicatifs, l'application, les méthodes utilisateurs
Ouais, un peu comme la sécurité quoi ;-)
Mes tests de charge depuis une machine connectée dessus se passaient parfaitement bien mais au moment du passage en prod, il semblerait que le nombre de sessions TCP à maintenir aient créé un blocage.
- conntrack activé?
- nombre maxi de fichier pouvant être ouverts?
- taille max du segment de mémoire partagée?
...
Conntrack desactivé, pareil pour la protection syn flood. Par contre, le nombre de filehandle autorisés pour Apache y est peut être pour quelque chose.
Idem pour shmmax : j'ai 32 Mo, ça peut être un facteur limitant ? # cat /proc/sys/kernel/shmmax 33554432
Bizarre quand même, mes tests avec ab depuis une machine connectée sur le même subnet donnaient de bons résultats. Va falloir que je reproduise le truc pour comprendre une bonne fois pour toutes.
Julien