3.3. Jocs de Proves i anàlisi de rendiment
3.3.1. Entorn de treball
El XicHttpd s'ha provat en dues màquines diferents, i s'ha generat la càrrega des d'una tercera, a continuació se'n mostren les característiques:
Desenvolupament i proves:
Portàtil Pentium IV 2,4 GHz 512 KB cau L2 (clònic)
512 MB de memòria RAM DDR
1024 MB de memòria d'intercanvi (SWAP)
SO: Debian woody (3.0) 2.4.18-bf2.4
Generador de càrrega:
AMD-K6 3D 400 MHz (clònic)
160 MB de memòria RAM (DIMM)
Memòria d'intercanvi per fitxer (uns 768 MB)
SO: Windows XP Professional V.2002
Característiques de la xarxa:
Ehternet amb parell trenat 10/100 UTP CAT 5
Entorn completament commutat
Connexions a 100 Mbps Full-Duplex PC-Switch
3.3.2. Proves bàsiques
Les primeres proves que es fan són per comprovar que realment el XicHttpd respongui el que toca, sobretot pel que fa als codis d'error de les respostes. Per aquestes comprovacions s'utilitza una connexió telnet des d'un altre terminal. Mostrem a continuació algunes d'aquestes sortides:
Petició correcte
aposai@Natasza:~/tfc/memo$ telnet Natasza 80 Trying 192.168.1.13... Connected to Natasza. Escape character is '^]'. GET /index_cgi.html HTTP/1.1 Host: Natasza HTTP/1.1 200 OK Date: Thu, 08 Jan 2004 09:30:54 GMT Server: XicHttpd v0.1 Last-Modified: Tue, 30 Dec 2003 20:43:52 GMT Content-Type: text/html Content-Length: 2298 Content-Encoding: identity <html> <head> <title>Exemple de CGI</title> ...
Petició correcte HTTP/1.0 (XicHttpd no suporta persistència en aquests tipus de connexions)
aposai@Natasza:~/tfc/memo$ telnet Natasza 80 Trying 192.168.1.13... Connected to Natasza. Escape character is '^]'. GET /index_cgi.html HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 08 Jan 2004 09:33:46 GMT Server: XicHttpd v0.1 Last-Modified: Tue, 30 Dec 2003 20:43:52 GMT Content-Type: text/html Content-Length: 2298 Content-Encoding: identity Connection: close <-- Força el tancament <html> <head> ... Connection closed by foreign host. aposai@Natasza:~/tfc/memo$
Un HEAD
HEAD /index_cgi.html HTTP/1.1 Host: Natasza HTTP/1.1 200 OK Date: Thu, 08 Jan 2004 09:40:12 GMT Server: XicHttpd v0.1 Last-Modified: Tue, 30 Dec 2003 20:43:52 GMT Content-Type: text/html Content-Length: 2298 Content-Encoding: identity (Resposta idèntica al GET sense l'entity-body) <-> HEAD acceptant gzip sobre el mateix recurs HEAD /index_cgi.html HTTP/1.1 Host: Natasza Accept-Encoding: gzip HTTP/1.1 200 OK Date: Thu, 08 Jan 2004 10:00:44 GMT Server: XicHttpd v0.1 Last-Modified: Tue, 30 Dec 2003 20:43:52 GMT Content-Type: text/html Content-Length: 678 <-- La mida es redueix dràsticament Content-Encoding: gzip
A continuació alguns errors
<-> Plana inexistent GET /foo.html HTTP/1.1 Host: Natasza HTTP/1.1 404 Not Found Date: Thu, 08 Jan 2004 09:42:47 GMT Server: XicHttpd v0.1 Content-Length: 65 Content-Type: text/html <html><body><center><h1>404 Not Found</h1></center></body></html> <-> Versió estranya, en llegir la primera línia respon descartant tot lo demés GET / HTTP/2.0 HTTP/1.1 505 HTTP Version Not Suported Date: Thu, 08 Jan 2004 09:44:16 GMT Server: XicHttpd v0.1 Content-Length: 81 Content-Type: text/html <html><body><center><h1>505 HTTP Version Not Suported</h1></center></body></html> <-> Mètode no implementat TRACE / HTTP/1.1 HTTP/1.1 501 Not Implemented Date: Thu, 08 Jan 2004 09:46:58 GMT Server: XicHttpd v0.1 Content-Length: 71 Content-Type: text/html <html><body><center><h1>501 Not Implemented</h1></center></body></html> <-> HTTP/1.1 Sense la capçalera HOST GET / HTTP/1.1 HTTP/1.1 400 Bad Request Date: Thu, 08 Jan 2004 09:48:41 GMT Server: XicHttpd v0.1 Content-Length: 67 Content-Type: text/html <html><body><center><h1>400 Bad Request</h1></center></body></html> <-> Intent d'accçes a un fitxer on no s'hi té permís GET /cgi-bin/exemple.cgi HTTP/1.1 Host: Natasza HTTP/1.1 403 Forbidden Date: Thu, 08 Jan 2004 09:49:54 GMT Server: XicHttpd v0.1 Content-Length: 65 Content-Type: text/html <html><body><center><h1>403 Forbidden</h1></center></body></html> <-> Igual que l'anterior però ara per processar dades GET /cgi-bin/exemple.cgi?var1=1 HTTP/1.1 Host: Natasza HTTP/1.1 200 OK Connection: close <-- El CGI força el tancament Content-Type: text/html; charset=ISO-8859-1 <?xml version="1.0" encoding="utf-8"?> ... <-> POST sense Content-Length POST / HTTP/1.1 Host: Natasza HTTP/1.1 411 Length Required Date: Thu, 08 Jan 2004 09:55:10 GMT Server: XicHttpd v0.1 Content-Length: 71 Content-Type: text/html <html><body><center><h1>411 Length Required</h1></center></body></html> <-> Petició amb males intencions, no ens molestem ni a contestar GET /../../../etc/passwd HTTP/1.1 Host: lala Connection closed by foreign host
3.3.3. Proves de rendiment
Les tres aplicacions de test que s'han aplicat són el Surge[1], el JMeter[2] d'Apache i el Web Stress[3] de Microsoft. A continuació es mostren algunes de les característiques de cada un i l'ús que n'he fet:
Surge: Genera una serie de fitxers *.txt de diferents mides que cal copiar a un directori accessible pel servidor, i després permet definir la quantitat de threads, connexions per fil i temps de duració de la prova, un petit defecte és que el tipus de client s'ha de definir en el moment de la compilació, personalment el vaig compilar per a connexions HTTP/1.1 amb pipelining. Per al meu cas s'utilitzen els valors de configuració per defecte (2000 fitxers), tot i així la interpretació dels resultats no és massa senzilla i com que el temps apreta s'utilitza únicament per fer les primeres proves sobre threads i prou. D'altra banda cal notar que es resultats tampoc eren massa fiables donat que s'executa sobre la mateixa màquina que el servidor. Es mostra a continuació el Surge treballant.
Natasza:/home/aposai/tfc/XicHttpd/benkmark# ./Surge 10 10 60 SURGE: Scalable URL Reference Generator Running 10 clients with 10 threads/client for 60 seconds SURGEmaster: 90054 objects in name sequence SURGEclient 0: running 10 threads SURGEclient 0: Object Count 0 SURGEclient 1: running 10 threads SURGEclient 2: running 10 threads SURGEclient 3: running 10 threads SURGEclient 4: running 10 threads SURGEclient 5: running 10 threads SURGEclient 5: Object Count 100 SURGEclient 6: running 10 threads SURGEclient 7: running 10 threads SURGEclient 6: Object Count 200 SURGEclient 8: running 10 threads SURGEclient 9: running 10 threads SURGEclient 8: Object Count 300 SURGEclient 0: Object Count 400 SURGEclient 3: Object Count 500 SURGEclient 4: Object Count 600 SURGEclient 4: Object Count 700 SURGEclient 0: Object Count 800 SURGEclient 2: Object Count 900 SURGEclient 5: Object Count 1000 .... Natasza:/home/aposai/tfc/XicHttpd/benkmark# ./pbvalclnt Surge.log Mean transfer delay = 0.004702 seconds Varience of transfer delay = 0.000146 seconds
JMeter: Està fet en Java i presenta un entorn gràfic prou entenedor. Per aquest cas cal definir completament l'entorn de proves, des de les URLs a les que es vol accedir, fins als mètodes, les capçaleres, etc. A l'hora de presentar els resultats tenim diferents opcions (Listeners) que ens permeten entre d'altres de veure gràfics, estadístiques d'accés per pàgina, la capçalera i el cos de les respostes... El problema és que consumeix molts recursos i la màquina de proves es quedava saturada molt abans que el servidor, de manera que tampoc ens podem refiar dels resultats. Tot i així em va permetre provar l'enviament de contingut comprimit amb gzip, a més de fer unes comparacions amb l'Apache (digueu-me agosarat), on la diferència més significativa era la dispersió en els temps de resposta del XicHttpd contra uns resultats més lineals de l'Apache. A continuació es pot veure una captura del JMeter en acabar un test fet amb 50 clients simultanis, compost d'11 grups d'accés aleatori a 11 planes cada un, en la meitat dels quals es demana compressió, l'objectiu és simplement comprovar el funcionament del XicHttpd en rebre accessos el màxim d'aleatoris possibles per simular un entorn real:
Web Stress: Tot i no mostrar uns resultats tan vistosos com el JMeter, tenim que també mostra una gran versatilitat a l'hora de preparar les proves, junt a que els requisits mínims són d'un P133 es converteix en un bon entorn per generar les proves de càrrega.
A continuació es defineixen les proves que s'han dut a terme amb aquest entorn:
Totes les proves accediran a 11 pàgines html més una imatge contingudes en el servidor, de mides entre 2 i 100 KB.
Test IDENTITY: Accés als arxius anteriors sense compressió.
Test GZIP: Accés als arxius anteriors amb compressió (excepte la imatge que el servidor l'enviarà tal qual).
Test TOT-CGI (tot menys CGI): Accés als arxius anteriors sense compressió, i se li afegeixen les 11 pàgines html demanant compressió.
Test TOT: Igual que l'anterior, però substituïm dues pàgines per dues peticions CGI, una amb un GET i l'altre amb un POST.
Cada test tindrà un delay aleatori entre cada request de 0 a 100 milisegons.
Cada prova té una durada de 2 minuts.
Les proves es comencen amb 100 clients i es repetiran amb increments de 100 per cada configuració del XicHttpd.
La configuració del XicHttpd permetrà un nombre de sobres de clients dinàmics, i repetirem les proves variant el nombre de threads estàtics i el valor del timeout de les connexions.
Resultats:
En les següents taules Hits són la quantitat de peticions, R/S són els request per segon, i Err indica si es produeixen errors en les connexions dels socket (no confondre-ho amb respostes errònies que no s'han produït).
Taula 3-2. XicHttpd: 5 threads estàtics, 30 segons de timeout
Clients TOT TOT-CGI IDENTITY GZIP Hits R/S Err Hits R/S Err Hits R/S Err Hits R/S Err 100 18750 156.02 NO 19397 161.41 NO 19193 161.03 NO 13387 111.40 NO 200 15315 127.44 SI 12655 105.31 NO 26600 223.20 NO 8265 68.76 NO 500 18540 154.28 SI 6012 50.03 NO 27115 225.02 NO 6530 54.71 NO Taula 3-3. XicHttpd: 50 threads estàtics, 15 segons de timeout
Clients TOT TOT-CGI IDENTITY GZIP Hits R/S Err Hits R/S Err Hits R/S Err Hits R/S Err 500 18756 156.07 SI 9144 76.09 NO 26771 224.28 NO 9012 75.62 NO En els resultats anteriors, a partir de 500 clients en amunt els valors no varien gaire, el que em fa pensar que o bé el client no dona per més, o bé la limitació és l'ample de banda ja que la càrrega de la màquina on corre el XicHttpd es mantenia constant (excepte pel nombre de processos clar). S'observa doncs que quan el servidor realitza menys processament de les dades, és a dir, en la prova IDENTITY, s'aguanta perfectament la càrrega mantenint una taxa de R/X molt alta, i veiem que tot i canviar la configuració del XicHttpd la influència és mínima. No passa el mateix en les dues proves que requereixen de la compressió de les dades (GZIP i TOT-CGI) on en la primera configuració s'observa com la productivitat cau en picat en augmentar el nombre de clients, però d'altra banda si mirem els resultats de la segona prova veiem que aquí el fet de disposar de molts més threads estàtics i d'un valor menor del timeout provoca un augment considerable del rendiment del servidor. Finalment els resultats de la prova TOT encara que semblin incoherents no ho són tant, ja que el fet que apareguin errors de connexió (entre 10 i 120) provoca que el client faci una nova petició sense esperar al timeout, aquest errors són degut a la implementació de la funcionalitat CGI ja que no està molt depurada, i en càrregues altes alguns dels subprocessos CGI es queden en estat zombie fins que reiniciem el servidor (no és tan crític quan tots els threads són dinàmics, ja que a la mort del thread també se'n moren els seus subprocessos).
En la prova següent canviem la columna de clients per la del timeout configurat al XicHttpd, es configura el Web Stress per tal que simuli la sortida d'un mòdem de 56 Kbps, i el nombre de clients són 200.
Taula 3-4. XicHttpd: 50 threads estàtics, 200 clients a 56 Kbps
Timeout TOT TOT-CGI IDENTITY GZIP Hits R/S Err Hits R/S Err Hits R/S Err Hits R/S Err 60 13267 110.39 NO 5033 42.23 NO 8472 71.09 NO 9771 81.31 NO 15 12034 100.13 SI 7079 58.90 NO 8610 71.64 NO 12116 100.81 NO L'alta productivitat de la prova TOT en comparació amb les altres s'explica pel fet que les respostes CGI ocupen poquets bytes i a més forcen el tancament de la connexió. Pel que fa a les demés podem trobar els resultats més representatius si comparem la prova IDENTITY amb la GZIP, on veiem que efectivament quan anem curts d'ample de banda el fet d'enviar el contingut comprimit augmenta considerablement la productivitat del servidor, i l'impacte es nota més encara si disminuïm el timeout del servidor.
Per acabar parlarem de les utilitats que s'han fet servir per tal de veure l'estat de la màquina sobre la que corre el XicHttpd ja que es considera un aspecte prou important. Tot i així el fet de determinar els requisits hardware mínims en funció de la càrrega ja no és un tema tan trivial, i s'haguéssin necessitat diferents entorns per tal de fer les proves.
top. Per al meu gust és una eina més encarada a l'administració, que no pas al monitoratge, que és el que es pretén, però ens pot ser útil en determinats moments per tal de veure quins processos utilitzen el processador, i quins estan intercanviats per exemple, a més es clar de la memòria que utilitzen així com la que comparteixen amb d'altres processos.
ps. La manera més ràpida de conèixer el PID del procés que volem matar, tot sovint però, l'he utilitzat per saber el nombre de threads del XicHttpd executant-se en un determinat moment, combinant la comanda amb un grep i un wc.
vmstat. Aquest monitor treu estadístiques generals del sistema, de manera que no sabrem quins processos hi ha, però en canvi ens permet veure l'estat del sistema durant un interval de temps i a més si volem en podem emmagatzemar les dades per analitzar-les més tard.
GKrellM[4]. És un monitor per les X, que ens permet de veure gràficament l'evolució de l'estat del sistema, així com l'ús de la xarxa. Sovint un cop d'ull al gkrellm ens ofereix la informació que necessitem ràpidament.
