Apache, el servidor web que més s’utilitza

Segons l’últim estudi que ha publicat Netcraft sobre servidors web, Apache continua agafant més avantatge sobre els seus contrincants i continua per 16é any consecutiu com al servidor web més utilitzat tal i com es pot veure en la següent gràfica:

 

ús de servidors web
Ús de servidors web segons Netcraft.com

 

També cal destacar la caiguda de Microsoft i l’ascens de nginx que són els que han patit les diferències més grans respecte al mes anterior.

 

Optimització d’Apache: keepalive

Apache és el servidor web més utilitzat de tot el món (15/11/2011) i per tant una de les tasques més importants a realitzar és la d’obtenir el màxim rendiment possible d’aquest servidor.  Aquí és on entra en joc Keepalive.

  

Què és el KeepAlive?

El protocol HTTP és un protocol en el qual és fa una connexió per obtenir un fitxer i aquesta connexió es tanca quan es reb el fitxer, el que fa les coses molt fàcils però no gaire eficients. Per aconseguir aquesta eficiencia es va crear una cosa anomenada KeepAlive amb la qual tant el servidor web com el navegador utilitzen la mateixa connexió per transferir múltiples fitxers.

La utilització  del Keepalive comporta beneficis i inconvenients. Pel cantó dels avantatges tenim que amb el KeepAlive activat aconseguim millorar la velocitat del nostre servidor web i redueix l’utilització de CPU però, per contra, s’incrementa l’utilització de de memòria en el servidor  ja que Apache ha de mantenir obertes les connexions esperant noves peticions per a les connexions obertes. 

Necessito utilitzar Apache KeepAlive?

Per tant la decissió de fer servir KeepAlive  o no depen de molts factors i tal i com s’ha comentat anteriorment, la RAM és un d’ells. Si en tenim poca serà milltr tenir-lo desactivat. Per contra si tenim poca CPU KeepAlive ens anirà molt bé si està actiu. També s’ha de tenir en compte si el nostre site tindrà molt de transit durant el dia pero espaiat en el temps o bé concentrat tot en un moment concentrat del temps. En el primer cas ens serà útil tenir KeppAlive actiu, mentre que en el segon cas ens interessarà mantenir-lo desactivat.

Com es configura Apache KeepAlive?

Com ja he comentat moltes vegades, jo faig servir normalment la distribució CentOS, en aquesta distribució hi ha un fitxer anomenat httpd.conf que es localitza a la següent ruta /etc/httpd/conf. Dins d’aquest fitxer hi ha els paràmetres de configuració de Apache i concretament pel que fa a KeepAlive hem de buscar una línea on apareixi la apraula KeepAlive i si esta a off el posem a on, quedant de la següent manera:

keepalive On

També hem de fixar número màxim de peticions que una connexió persistent atendrà, o el que és el mateix, configurar el paràmetre MaxKeepAliveRequests. El valor recomenat per a aquest paràmetre pot estar entre 50 i 75. Per últim ens queda configurar el temps que el servidor esperarà per noves peticions de clients connectats, o el que es el mateix, retocar el paràmetre KeepAliveTimeout. Això ens serveix per utilitzar la menor RAM possible mentre s’esperen peticions. Un valor entre 1 i 5 segons es força adequat.

Apache Benchmark (ab). Prova de càrrega del nostre website

Que és Apache Benchmark?

Tens una web personal a un servidor web i vols saber quin rendiment té? Doncs bé, a Linux hi ha una utilitat que és diu Apache Benchmarking (ab) que serveix per realitzar proves de càrrega del nostre servidor web, o sigui que és una utilitat que esta dissenyada per saber com es comporta la configuració actual de nostre servidor web. Ara bé no és tracta de simplement de saber el temps de càrrega d’una pàgina ja que hi ha retards en la xarxa i això pot fer que els resultats obtinguts en un moment variin considerablement als d’un altre. El que si que pot detectar aquesta utilitat és el temps de càrrega màxim per a un número determinat d’usuaris que intenten accedir a la teva pàgina.També pot ser interessant mirar el temps addicional que pot trigar en carregar la mateixa pàgina si per exemple es duplica el número de visitants.

Les proves que es facin amb ab s’han de repetir vàries vegades per a evitar desviacions i així quedar-nos amb el millor resultat.

 

Els possibles paràmetres que accepta ab són:

ab  [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file  ]  [  -P  proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ] [ -X proxy[:port] ] [  -y  <tr>-attributes  ]  [  -z  <td>-attributes  ]
 [http://]hostname[:port]/path
-A auth-username:password           Supply  BASIC Authentication credentials to the server. The username and password are separated by
 a single : and sent on the wire base64 encoded. The string  is  sent  regardless  of  whether  the
 server needs it (i.e., has sent an 401 authentication needed).

 -c concurrency
 Number of multiple requests to perform at a time. Default is one request at a time.

 -C cookie-name=value
 Add  a  Cookie:  line  to the request. The argument is typically in the form of a name=value pair.
 This field is repeatable.

 -d     Do not display the "percentage served within XX [ms] table". (legacy support).

 -e csv-file
 Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%)  the
 time (in milliseconds) it took to serve that percentage of the requests. This is usually more use-
 ful than the ’gnuplot’ file; as the results are already ’binned’.

 -g gnuplot-file
 Write all measured values out as a ’gnuplot’ or TSV (Tab separate values) file. This file can eas-
 ily  be  imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are
 on the first line of the file.

 -h     Display usage information.

 -H custom-header
 Append extra headers to the request. The argument is typically in the form of a valid header line,
 containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").

 -i     Do HEAD requests instead of GET.

 -k     Enable  the  HTTP  KeepAlive  feature,  i.e.,  perform  multiple requests within one HTTP session.
 Default is no KeepAlive.
-n requests   Number of requests to perform for the benchmarking session. The default is to just perform a  sin-
 gle request which usually leads to non-representative benchmarking results.

 -p POST-file
 File containing data to POST.

 -P proxy-auth-username:password
 Supply  BASIC  Authentication credentials to a proxy en-route. The username and password are sepa-
 rated by a single : and sent on the wire base64 encoded. The string is sent regardless of  whether
 the proxy needs it (i.e., has sent an 407 proxy authentication needed).

 -q     When  processing  more  than  150 requests, ab outputs a progress count on stderr every 10% or 100
 requests or so. The -q flag will suppress these messages.

 -s     When compiled in (ab -h will show you) use the SSL protected https rather than the http  protocol.
 This feature is experimental and very rudimentary. You probably do not want to use it.

 -S     Do  not  display  the median and standard deviation values, nor display the warning/error messages
 when the average and median are more than one or two  times  the  standard  deviation  apart.  And
 default to the min/avg/max values. (legacy support).

 -t timelimit
 Maximum  number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this
 to benchmark the server within a fixed total amount of time. Per default there is no timelimit.

 -T content-type
 Content-type header to use for POST data.

 -v verbosity
 Set verbosity level - 4 and above prints information on headers, 3 and above prints response codes
 (404, 200, etc.), 2 and above prints warnings and info.
-V     Display version number and exit.

 -w     Print out results in HTML tables. Default table is two columns wide, with a white background.

 -x <table>-attributes
 String to use as attributes for <table>. Attributes are inserted <table here >.

 -X proxy[:port]
 Use a proxy server for the requests.

 -y <tr>-attributes
 String to use as attributes for <tr>.

 -z <td>-attributes
 String to use as attributes for <td>.

 

Per a realitzar les proves amb aquesta utilitat és important que la prova es faci des d’un altre màquina que no formi part de la xarxa del servidor que volem provar ja que sinó els temps que obtindríem serien evidentment més petits dels esperats.

En el meu cas he fet la prova des el meu ordinador d’escriptori fins al servidor on esta allotjat aquest blog. Concretament sobre la següent URL http://prova.jjberdullas.com. Que serveix una pàgina tant simple com aquesta:

 

<html>
<head>
 <title>prova</title>
</head>
<body>
<?php
 echo "aixo es una prova";
?>
</body>
</html>

Quan es crida la comanda ab s’ha d’afegir una barra final a la URL sobre la qual es vol fer la prova.

Sobre les quals he fet 2 proves diferents:

  • 100 consultes amb 20 usuaris simultanis
[usuari@nom_servidor ~]$ ab -n 1000 -c 20 http://prova.jjberdullas.com/

Server Software:        Apache/X.X.X
Server Hostname:        prova.jjberdullas.com
Server Port:            80

Document Path:          /
Document Length:        84 bytes

Concurrency Level:      20
Time taken for tests:   12.860595 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      276276 bytes
HTML transferred:       84084 bytes
Requests per second:    77.76 [#/sec] (mean)
Time per request:       257.212 [ms] (mean)
Time per request:       12.861 [ms] (mean, across all concurrent requests)
Transfer rate:          20.92 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:       42  115  35.2    127     285
Processing:    46  139  32.5    141     290
Waiting:       45  138  32.6    140     289
Total:         89  254  43.1    247     532
  • 2000 consultes amb 20 usuaris simultanis
[usuari@nom_servidor ~]$ ab -n 2000 -c 20 http://prova.jjberdullas.com/

Server Software:        Apache/X.X.X
Server Hostname:        prova.jjberdullas.com
Server Port:            80

Document Path:          /
Document Length:        84 bytes

Concurrency Level:      20
Time taken for tests:   25.16090 seconds
Complete requests:      2000
Failed requests:        0
Write errors:           0
Total transferred:      552000 bytes
HTML transferred:       168000 bytes
Requests per second:    79.95 [#/sec] (mean)
Time per request:       250.161 [ms] (mean)
Time per request:       12.508 [ms] (mean, across all concurrent requests)
Transfer rate:          21.55 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:       42  119  21.9    132     147
Processing:    43  129  22.2    134     234
Waiting:       42  127  22.2    133     234
Total:         85  248  22.2    246     328

Percentage of the requests served within a certain time (ms)
 50%    246
 66%    250
 75%    256
 80%    274
 90%    279
 95%    282
 98%    285
 99%    287
 100%    328 (longest request)

De lo cual es pot deduir que amb el mateix número d’usuaris concurrents i el doble de peticions, es duplica el temps per realitzar la prova però amb la configuració actual del nostre servidor, es manté el número de peticions per segon que són ateses (aproximadament 75), temps per petició i el temps per petició sobre totes les peticions  concurrents.