5 consells per augmentar el rendiment del vostre servidor web Apache

Segons un informe recent de Netcraft (una coneguda empresa d'Internet que proporciona, entre altres serveis, estadístiques d'ús del navegador web), Apache continua sent el servidor web més utilitzat entre els llocs i els ordinadors orientats a Internet.

A més, Apache continua experimentant el creixement més gran entre els principals servidors web, seguit de Nginx i IIS. Així, si sou un administrador del sistema encarregat de gestionar les instal·lacions d'Apache, heu de saber com assegurar-vos que el vostre servidor web funcioni al màxim de la seva capacitat segons les vostres necessitats (o les del vostre client).

En aquest article parlarem d'uns quants consells que us ajudaran a assegurar-vos que Apache funcionarà sense problemes i serà capaç de gestionar el nombre de sol·licituds que espereu de clients remots.

Tanmateix, tingueu en compte que Apache no va ser dissenyat amb l'objectiu d'establir rècords de referència, però, tot i així, encara és capaç d'oferir un alt rendiment en gairebé qualsevol cas d'ús que us pugui imaginar.

CONSELL núm. 1: manteniu Apache actualitzat a la seva darrera versió

No cal dir que tenir instal·lada la darrera versió d'Apache és probablement una de les primeres coses que cal tenir en compte. A partir del 19 de novembre de 2015, l'última versió d'Apache disponible als repositoris CentOS 7 és la 2.4.6, mentre que a Debian és la 2.4.10.

Tanmateix, pot haver-hi una millora recent o una correcció d'errors que s'hagi afegit a una versió estable recentment llançada, que després es posa a disposició per baixar i instal·lar des de la font. Aquí també es proporcionen instruccions de compilació i instal·lació; només recordeu que si trieu aquest mètode d'actualització, és possible que vulgueu fer una còpia de seguretat dels vostres fitxers/llocs/amfitrions virtuals de configuració actuals com a precaució.

En qualsevol cas, podeu comprovar la vostra versió instal·lada actualment de la següent manera:

# httpd -v               [On RedHat/CentOS based systems]
# apache2 –v             [On Debian/Ubuntu based systems]

Com a regla general, seguiu el mètode d'actualització proporcionat pel gestor de paquets de la vostra distribució escollida (yum update httpd o aptitude safe-upgrade apache2, per a CentOS o Debian, respectivament) tret que no hi hagi una altra manera. Podeu llegir les notes de llançament més recents a la secció Documentació d'Apache al lloc web del projecte del servidor HTTP Apache.

CONSELL núm. 2: Si utilitzeu un nucli anterior a 2.4, considereu actualitzar-lo ara

Per què? Les versions del nucli 2.4 i posteriors tenen la trucada al sistema del nucli sendfile activada per defecte. Això, al seu torn, facilita les transferències de fitxers de xarxa d'alt rendiment (que es desitgen en el context de les comunicacions servidor web-client) i permet a Apache oferir contingut estàtic més ràpidament i amb una utilització més baixa de la CPU realitzant operacions de lectura i enviament simultànies.

Podeu veure el vostre nucli instal·lat actualment amb:

# uname -r

i compareu-lo amb l'últim nucli estable a www.kernel.org (4.3 en el moment d'escriure aquest article).

Tot i que és un procés no pensat per a principiants, actualitzar el vostre nucli és un exercici interessant per aprendre més sobre els elements interns de Linux.

CONSELL núm. 3: trieu el mòdul de processament múltiple (MPM) que millor funcioni per al vostre cas

A la pràctica, els MPM amplien la funcionalitat modular d'Apache, ja que us permeten decidir com configurar el servidor web per vincular-se als ports de xarxa de la màquina, acceptar sol·licituds dels clients i utilitzar processos secundaris (i fils, alternativament) per gestionar aquestes peticions.

A partir de la versió 2.4, Apache ofereix tres MPM diferents per triar, segons les vostres necessitats:

  1. El prefork MPM utilitza diversos processos secundaris sense fils. Cada procés gestiona una connexió alhora sense crear fils separats per a cadascun. Sense entrar en massa detalls, podem dir que voldreu utilitzar aquest MPM només quan depureu una aplicació que utilitzi, o si la vostra aplicació ha de tractar, mòduls que no són segurs per a subprocesos com el mod_php.
  2. El treballador MPM utilitza diversos fils per procés secundari, on cada fil gestiona una connexió alhora. Aquesta és una bona opció per a servidors d'alt trànsit, ja que permet gestionar més connexions simultànies amb menys RAM que en el cas anterior.
  3. Finalment, l'esdeveniment MPM és l'MPM predeterminat a la majoria d'instal·lacions d'Apache per a les versions 2.4 i posteriors. És similar al MPM de treball, ja que també crea múltiples fils per procés fill, però amb un avantatge: fa que les connexions KeepAlive o inactives (mentre romanguin en aquest estat) siguin gestionades per un sol fil, alliberant així memòria que pot s'assignaran a altres fils. Aquest MPM no és adequat per utilitzar-lo amb mòduls no segurs per a subprocesos com mod_php, per als quals s'ha d'utilitzar un substitut com PHP-FPM.

Per comprovar el MPM utilitzat per la vostra instal·lació d'Apache, podeu fer:

# httpd -V

La imatge següent mostra que aquest servidor web en particular utilitza el MPM prefork.

Per canviar-ho, haureu d'editar:

# /etc/httpd/conf.modules.d/00-mpm.conf          [On RedHat/CentOS based systems]
# /etc/apache2/mods-available/<mpm>.load   [On Debian/Ubuntu based systems]

On pot ser mpm_event, mpm_worker o mpm_prefork.

i descomenteu la línia que carrega el mòdul desitjat així:

LoadModule mpm_event_module modules/mod_mpm_event.so

Nota: Per fer que l'esdeveniment MPM funcioni a Debian, potser haureu d'instal·lar el paquet libapache2-mod-fastcgi des dels dipòsits no lliures.

A més, per a CentOS necessitareu php-fpm (juntament amb fcgi i mod_fcgid), mentre que a Debian s'anomena php5-fpm (juntament amb apache2-mpm-event).

Finalment, però no menys important, reinicieu el servidor web i el servei php-fpm (o php5-fpm) recentment instal·lat:

# systemctl restart httpd php-fpm && systemctl enable httpd php-fpm

# systemctl restart apache2 php5-fpm && systemctl enable apache2 php5-fpm

Tot i que podeu configurar Apache perquè utilitzi un MPM específic, aquesta configuració es pot substituir per host virtual de la mateixa manera que s'ha indicat anteriorment.

Només cal que deixeu anar les etiquetes corresponents al fitxer de configuració de cada host virtual i ja esteu preparat, però assegureu-vos que feu servir un i només un MPM per vhost.

Finalment, tingueu en compte que, independentment de la distribució escollida, php-fpm es basa en la implementació de FastCGI, que és la raó per la qual vaig recomanar les instal·lacions de paquets addicionals abans.

Per obtenir més detalls i exemples sobre php-fpm i com pot augmentar el rendiment d'Apache juntament amb l'esdeveniment MPM, hauríeu de consultar la documentació oficial.

Això és el que veig després de canviar el MPM predeterminat de prefork a esdeveniment al mateix quadre que es mostra a la imatge anterior:

A CentOS 7, haureu d'assegurar-vos que els serveis http i https estan habilitats a través del tallafoc i que les interfícies de xarxa s'afegeixen correctament a la zona predeterminada.

Per exemple:

# firewall-cmd --zone=internal --add-interface=tun6to4 
# firewall-cmd --zone=internal --add-interface=tun6to4 --permanent 
# firewall-cmd --set-default-zone=internal 
# firewall-cmd --add-service=http 
# firewall-cmd --add-service=https 
# firewall-cmd --add-service=http --permanent 
# firewall-cmd --add-service=https --permanent 
# firewall-cmd --reload

La raó per la qual estic plantejant això és perquè recentment vaig experimentar un problema en què la configuració predeterminada del tallafoc en un VPS al núvol impedia que php-fpm i Apache processessin fitxers php.

Com a prova bàsica (estic segur que se'n poden pensar de més complicades o estressants), crearé un fitxer php que comprovi l'existència d'un altre fitxer anomenat test.php al mateix directori de dos CentOS. 7 servidors amb les mateixes característiques de maquinari i càrrega però amb MPM diferent. Un d'ells utilitzarà event i l'altre utilitzarà prefork:

Aquest és el codi php que he desat en un fitxer anomenat checkiffileexists.php:

<?php
$filename = 'test.php';

if (file_exists($filename)) {
    echo "The file $filename exists";
} else {
    echo "The file $filename does not exist";
}
?>

A continuació, executarem l'eina de referència d'Apache (ab) amb 200 sol·licituds simultànies fins a completar 2000 sol·licituds:

# ab -k -c 100 -n 2000 localhost/checkiffileexists.php

Anem a fer la prova i comparem els resultats. Preste atenció a les estadístiques de rendiment:

Com podeu veure, el rendiment del servidor amb esdeveniment és molt superior al seu homòleg prefork en tots els aspectes d'aquesta prova.

CONSELL #4: assigneu la memòria RAM amb prudència per a Apache

Potser l'element de maquinari més crític a tenir en compte és la quantitat de RAM assignada per a cada procés d'Apache. Tot i que no podeu controlar-ho directament, podeu restringir el nombre de processos secundaris mitjançant la directiva MaxRequestWorkers (abans coneguda com MaxClients a Apache 2.2), que posarà límits a l'ús de RAM per part d'Apache. De nou, podeu establir aquest valor per host o per host virtual.

Per fer-ho, hauríeu de prendre nota de la quantitat mitjana de memòria RAM utilitzada per Apache i, a continuació, multiplicar-la pel nombre de MaxRequestWorkers, i aquesta és la quantitat de memòria que s'assignarà per als processos d'Apache. Una cosa que mai voleu que faci el vostre servidor web és començar a utilitzar l'intercanvi, ja que això disminuirà significativament el seu rendiment. Per tant, sempre hauríeu de mantenir l'ús de la memòria RAM per part d'Apache dins dels límits que us podeu permetre i mai confiar en l'intercanvi.

Per exemple, el bloc següent restringirà el nombre de clients simultanis a 30. Si més clients arriben a l'amfitrió, poden experimentar un retard o una fallada momentània que es pot resoldre fàcilment actualitzant el navegador. Tot i que això es pot considerar indesitjable, és més saludable per al servidor i, a la llarga, també és millor per al vostre lloc.

Podeu col·locar aquest bloc dins de /etc/httpd/conf/httpd.conf o /etc/apache2/apache2.conf, depenent de si feu servir CentOS o Debian.

Tingueu en compte que el mateix principi s'aplica a tots els MPM: faig servir event aquí per continuar amb el concepte descrit al consell anterior:

<IfModule mpm_event_module>
    StartServers 3
    MinSpareThreads          25
    MaxSpareThreads          75
    ThreadLimit                      64
    ThreadsPerChild          25
    MaxRequestWorkers    30
    MaxConnectionsPerChild    1000
</IfModule>

En qualsevol cas, és molt recomanable que consulteu els documents d'Apache 2.4 per veure quines directives estan permeses per a l'MPM escollit.

CONSELL #5: Coneix les teves aplicacions

Com a regla general, no hauríeu de carregar cap mòdul Apache que no sigui estrictament necessari perquè la vostra aplicació funcioni. Això requerirà almenys un coneixement general de les aplicacions que s'executen al vostre servidor, especialment si sou administrador del sistema i hi ha un altre equip encarregat del desenvolupament.

Podeu llistar els mòduls carregats actualment amb:

# httpd -M          [On RedHat/CentOS based systems]
# apache2ctl -M     [On Debian/Ubuntu based systems]

Per descarregar/desactivar mòduls a CentOS, haureu de comentar la línia que comença amb LoadModule (ja sigui al fitxer de configuració principal o en un auxiliar dins de /etc/httpd/conf.modules.d.

D'altra banda, Debian proporciona una eina anomenada a2dismod per desactivar mòduls i s'utilitza de la següent manera:

# a2dismod module_name

Per tornar-lo a activar:

# a2enmod module_name

En qualsevol cas, recordeu reiniciar Apache perquè els canvis tinguin efecte.

Resum

En aquest article hem revisat 5 consells que us ajudaran a ajustar el servidor web Apache i augmentar-ne el rendiment. A més, hauríeu de recordar que l'optimització i el rendiment sense seguretat no tenen sentit, per la qual cosa també us recomanem que consulteu l'article de consells d'enduriment d'Apache a linux-console.net.

Atès que no podem cobrir adequadament tots els aspectes d'aquest tema en aquest article, potser us penseu altres idees que us agradaria compartir amb la resta de la comunitat. Si és així, no dubteu a fer-nos-ho saber mitjançant el formulari de comentaris a continuació.