Bon, unreal, t’es bete.
[quote name=‹ unreal › date=’ 23 Mar 2005, 14:05’][quote]
6599 fetches, 1020 max parallel, 1.26617e+07 bytes, in 180 seconds
1918.74 mean bytes/connection
36.661 fetches/sec, 70342.9 bytes/sec
msecs/connect: 8523.26 mean, 54825.7 max, 28.945 min
msecs/first-response: 4850.07 mean, 58228.2 max, 48.429 min
3461 timeouts
3289 bad byte counts
HTTP response codes:
code 200 – 3500[/quote]
Les « bad byte », ca veut rien dire, je crois que c’est parce que le soft a du mal avec le html 1.1. Par contre, les timeout, c’est pas bien.
[/quote]
On va revenir sur ton interpretation des bad byte, c’est fun aussi.
Mais d’abord, j’aimerais savoir ce qui te permet de dire que le serveur de GB a pas bien tenu le coup.
Effectivement, on apprend qu’il ya eu 3461 timeout. My My. En general, en reseau, quand ca timeout, c’est que le cable est coupe - cas d’ecole.
Donc ca serait pas mal de savoir, deja, quelle est la taille de la page:
[quote]$ ./http_load -rate 1 -seconds 10 url
9 fetches, 1 max parallel, 33417 bytes, in 10 seconds
3713 mean bytes/connection
0.899996 fetches/sec, 3341.68 bytes/sec
msecs/connect: 0.23 mean, 0.286 max, 0.166 min
msecs/first-response: 2.761 mean, 6.102 max, 1.938 min
HTTP response codes:
code 200 – 9[/quote]
On apprend ici que la page fait 3713 octets en moyenne, et vu le rate peu eleve qu’on a mis, ca doit etre la taille reelle. (la page peut etre plus petite quand on sauvegarde avec un navigateur, attention au texte dos/texte unix et aux headers http)
On apprend aussi qu’il y a un fetch manquant, et le probleme se repete quelque soit le nombre de seconde ou le rate: Quand ca roule, fetch = (rate * sec)-1
Mais revenons a nos 3713 octets. Ca nous fait donc 185650 octets qui devront etre transfere en une seconde. 180ko/s. Huuum… GB, il a une connexion freebox, ca plafonne a 100ko/s ces trucs la, nan?
Oh mais donc, le test, il a pas marche, parce que la BP etait pas suffisante, pas parce que le serveur etait sur les genoux. roooooh c’est dingue.
Et c’est ca qui m’eclate: Tu interprete a la volee les valeurs sans te poser de questions. Genre parallel max, je sais pas ce que c’est, c’est pas marque dans le manpage et franchement, ton interpretation ne me parait pas convaincante.
En revanche, pour le bad bytes count, tu aurais lu la doc, tu aurais su que c’est le nombre de page dont la taille ne matche pas avec le premier essai: CA VEUT DIRE QUELQUE CHOSE, au contraire: Si t’as des bad bytes count, c’est que ta BP est sature. (Ca peut avoir d’autres causes, mais c’est la principale: j’ai eu le probleme avec le test de phpinfo quand j’en ai demande trop par secondes: overload de la 100mb).
Pour la petite histoire, j’ai fait le test en local sur la machine de GB:
[quote]$ ./http_load -rate 200 -seconds 120 url
23999 fetches, 144 max parallel, 8.91083e+07 bytes, in 120 seconds
3713 mean bytes/connection
199.992 fetches/sec, 742569 bytes/sec
msecs/connect: 1.80602 mean, 2999.79 max, 0.077 min
msecs/first-response: 11.5233 mean, 717.114 max, 1.484 min
HTTP response codes:
code 200 – 23999[/quote]
(dingue non)
Au dela de 200, le soft de test s’emballe et raconte nawak (plus de fetch que de requetes, c’est louche), je pense que c’est parce que je fais le test sur la machine qui a le serveur.
Sinon, j’ai regarde la page de GB. En fait, http_load ne fait qu’execute la page d’index, il ne lance pas les requetes pour les images autogenere en GD: c’est comme si on chargeait la page PHP sans demander les images que se generent a la volee. (pour voir ca, faites le avec lynx, c’est pareil)
[quote name=‹ unreal › date=’ 23 Mar 2005, 19:07’]Normalement c’est impossible d’avoir des memory leak avec apache sous unix. Il marche par folk, donc les processus sont detruits tres frequemment.
[right][post=« 343669 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Oui oui, That’s all foLks, je vais etre trop cool et considerer que c’est une faute de frappe. BOUARF!
LoneWolf
Putain unreal, comment t’as deconne la 