Com augmentar les connexions simultànies a Apache

Avui vinc a parlar-vos un cop més d'un dels serveis web més usats en tot el món: El servidor web Apache2.

Es tracta d'un tema de què s'ha parlat multitud de vegades, però ara vinc a parlar-vos d'una altra característica molt a tenir en compte amb aquest servei: El límit de connexions simultànies. Tant se val si tenim molt bàsic o una nau espacial amb un processador i7 i 32 GB de ram ...

El límit de connexions simultànies sempre serà el mateix llevat que prenguem les mesures adequades, el que significa que si volem tenir moltes persones connectades a el mateix temps, no només requerirem una bona maquinari, sinó que també una bona configuració.

En aquest cas no cal instal lar res, tot es basa en simples conceptes que cal tenir en compte per configurar apatxe; conceptes que cal tenir molt clars abans de voler fer qualsevol canvi.

apache2_logo

El primer que caldria pensar és: Quina capacitat té el meu equip? Quantes connexions simultànies pot arribar a suportar el meu equip si ho arribo a forçar el màxim possible? Tot això depèn d'un únic factor; la memòria RAM (Random Access Memory).

A més la memòria RAM, major el nombre de connexions, si bé no hi ha un valor fix (és a dir X clients per cada X ram), és per això que abans de res és important fer uns petits càlculs al nostre servidor web, amb el finalitat de conèixer els nostres límits.

El primer que caldria saber és quanta memòria RAM de mitjana consumeix cada connexió a Apache, ja que cada connexió establerta suposa un cert consum de RAM en el sistema ... Òbviament no totes les connexions consumeixen la mateixa ram, de manera que caldria fer una mitjana ... Tot això es pot obtenir amb la següent comanda:

ps -ylC apache2 --sort: rss | awk '{SUM + = $ 8; R + = 1} END {print SUM / I / 1024} '

El resultat obtingut estaria representat en megabytes i pot variar depenent de el nombre de connexions actives, el tipus de pàgines a les que s'accedeix, etc ... Per això és recomanable realitzar la prova amb diferents pestanyes obertes; cadascuna d'elles mostrant diferents continguts a ser possible. En el meu cas per exemple el resultat ha estat de 9.5458 el que si ho arrodonim a l'superior serien 10 MB de RAM consumits de mitjana per connexió.

A més és important saber quanta memòria RAM és consumida per la resta de processos que hi ha actius en el sistema, ja que el servei web no és l'únic que corre en el sistema operatiu i cal deixar memòria RAM lliure al servidor perquè pugui executar la resta de tasques. Això es pot obtenir amb la comanda mostrat a continuació:

ps -N -ylC apache2 --sort: rss | awk '{SUM + = $ 8} END {print SUM / 1024}'

El resultat obtingut també seria representat en megabytes, i ens mostraria amb força precisió la quantitat de RAM consumida per la resta de processos; en el meu cas 800 MB. Amb aquesta informació podríem fer un càlcul general de la quantitat de connexions simultànies que podríem tenir; calculo que obtindríem mitjançant una operació ben senzilla.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONEXIÓN

Amb aquesta fórmula en mà, imaginem que tenim un equip amb 4 GB RAM, és a dir 4096 MB i que el nostre equip a mostrat els resultats abans esmentats; el càlcul seria:

(4096 - 800) / 10 = 329 connexions simultànies

El problema amb aquest càlcul és que un massa extremista, ja que ens consumiria tota la RAM (fent que el servidor consumeixi swap) i, a més, en cas de tenir una base dades, com MySQL o qualsevol altra, les connexions a aquesta també consumirien RAM , de manera que el nombre obtingut es podria qualificar com un nombre utòpic. Per això, per deixar lliure la memòria per a possibles processos addicionals i més contemplar la possibilitat que s'executin connexions a alguna base de dades, reduiríem el nombre de connexions a 250.

Ara que tenim el nostre nombre de connexions simultànies màximes, caldria preparar Apache per poder rebre aquest nombre, la qual cosa es realitza en el fitxer de configuració d'aquest anomenat apache2.conf, El qual està allotjat en / etc / apache2.

El fitxer en qüestió segueix una estructura basada en mòduls, Cada un amb el seu nom corresponent, però només ens interessaria un d'ells, el nom és  mpm_prefork_module. El mòdul en qüestió posseeix les següents dades per defecte:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Aquest mòdul té una sèrie de paràmetres molt importants, tot i que n'hi ha un d'ells que ens interessaria especialment, anomenat MaxClients. Aquest paràmetre especifica el nombre màxim de connexions simultànies i caldria modificar-lo a 250.

Un detall a tenir en compte és que quan s'especifica un valor diferent a el de per defecte en aquest paràmetre, cal afegir un altre més just ABANS d'aquest. Dit paràmetre s'anomena ServerLimit i estableix el límit de connexions que podria «aguantar» el servidor tot i que es troba fora de el límit.

El paràmetre ServerLimit sempre ha de ser lleugerament superior a l'MaxClients i aquí a l'tenir poc marge de maniobra caldria establir un límit de 270. Això faria que el mòdul quedés de la següent manera:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0

Ara únicament faltaria reiniciar el servei Apache mitjançant la comanda: 

/etc/init.d/apache2 restart

Amb això ja podríem gaudir del nostre servidor web optimitzat.

Salutacions.


22 comentaris, deixa el teu

Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   zetatí va dir

    Gràcies pel post!

    1.    Drassill va dir

      M'alegro que t'hagi resultat útil.

      Salutacions.

  2.   Miguel Ángel va dir

    Hi ha una manera de fer clúster amb Apache i dos servidors, pots explicar com funciona ??

    1.    Drassill va dir

      Encara que he llegit alguna cosa de teoria a l'respecte, mai ho he aplicat a la pràctica. Tot i així, potser aquest article et pugui donar alguna guia a l'respecte, tot i que repeteixo que no he tingut l'oportunitat de passar-ho a la pràctica:

      http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/

    2.    Eduardo Jalil va dir

      ja té estona que vas preguntar, si no solucionaste; jo tinc un esquema de balanceig amb un tercer que funge com file system, apuntes les carpetes que estan en var / www / html / (en el meu cas) a l'file system, així comparteixen la mateixa informació, i possiblement requeriras una ip virtual que respongui i redireccioni a les ips de l'els apatxes, per això pots ocupar un haproxy i si ho vols en alta disponibilitat pots integrar KeepAlive per si algun cau l'altre segueixi responent, o també si ja comptes amb domini per a l'aplicacion, pots balancejar amb pound fent backends cap als dos servidors, per a casos específics com moodle o certes aplicacions que connecten amb base de dades a mysql, hauries de crear un usuari per servidor d'app que apunti a la mateixa base.

  3.   shamaru va dir

    moltes gràcies pel post, té tot la raó la ram és el càlcul primordial, encara que m'imagino que calcular també la quantitat màxima de processos que pot gestionar el nostre processador (clar primer fent el càlcul de la memòria principal) i com estaria distribuït el disc dur (particions Exemple / var = 1TR).

    1.    Drassill va dir

      Et dono tota la raó; tot és important, a l'igual que el control de la temperatura entre altres coses. Òbviament un processador potent pot executar un major nombre de tasques simultàniament amb molta eficiència, però l'objectiu d'aquest post era explicar la importància que té la RAM pel que fa a nombre de connexions simultànies.

      Una bona manera de controlar tots aquests factors i veure si el nostre processador no està saturat o si ens queda poca RAM lliure, seria mitjançant l'ús d'un script en bash. Pot ser sigui interessant aquest post que vaig fer fa uns dies a l'respecte que et deixo en el següent enllaç; es tracta d'un monitoratge global però que pot resultar-se a un interessant:

      http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html

      Salutacions

  4.   Sergio S va dir

    Molt bona la nota, moltes gràcies!

    1.    Drassill va dir

      Moltes gràcies! Espero que hagis pogut treure-li profit.

  5.   pallasso va dir

    no vull ser un cretí ...
    ... però a l'augmentar la quantitat de connexions no deixes mes vulnerable a un ataqur DDoS?

    1.    Drassill va dir

      No és cap pregunta cretina tranquil. La veritat és que augmentant el nombre de connexions simultànies, en part fortificamos Apache contra els atacs DDOS, ja que has de tenir en compte que el nombre de connexions simultànies màximes establertes al servidor, són el nombre de connexions màximes totals, no les procedents de un sol usuari. Així doncs, mentre que a el principi només podíem suportar 150 connexions simultànies (ja siguin connexions d'un origen legítim o no) ara podem comptar amb tantes com el nostre servidor suport, requerint un major nombre de connexions a el mateix temps per quedar-se sense servei. Òbviament el augmentar el nombre màxim de connexions no és una forma de protegir-se d'aquest tipus d'atacs sinó que caldria implementar polítiques de tallafocs. Si per exemple el servei web que es vol posar va ser exposat a internet, una mesura de seguretat que es podria implementar seria l'addició d'aquestes línies al nostre tallafocs:

      iptables -A INPUT -p tcp -syn -dport 80 -m connlimit -connlimit-upto 10 -m state -state NEW -j ACCEPT

      iptables -A INPUT -p tcp -dport 80 -m state -state ESTABLISHED, RELATED -j ACCEPT

      iptables -A INPUT -p tcp -dport 80 -j DROP

      1.    pallasso va dir

        una de les característiques dels Atacs DDoS és que un atacant pot aparentar enviar paquets des de diverses direccions diferents, el que evita que el flux de paquets provingui només d'una direcció.

    2.    Drassill va dir

      Tens raó en el sentit que un tallafocs com el que he posat no és massa eficient contra un atac DDOS, ja que prové de diferents orígens. Tot i així, és millor limitar el nombre de connexions a 10 per cada un d'aquests orígens en comptes de no tenir un límit, fent que cada origen pugui establir un centenar de connexions o més.

      De tota manera el kit de la qüestió és que com més connexions simultànies suporti el servidor, més difícil serà tombar amb un atac DDOS, de manera que més que facilitar que la pàgina sigui tombada per un atacant, el dificultaria.

      Salutacions.

  6.   eliotime3000 va dir

    Bona. Per ara segueixo amb Nginx al meu lloc per no torturar el VPS que tinc.

  7.   Bruno Cascio va dir

    Bon post @Drassill!

    Jo volia aportar amb alguna cosa potser més estadístic que de configuració.
    Si bé la forma més fàcil i ràpida de calcular el paràmetre de consum és amb la mitjana, potser podríem ser més rigorosos i fer servir la "mitjana" en lloc de la "mitjana". De que ens salvaria? De que se'ns disparin els números en cas que una connexió hagi consumit molta memòria. Per exemple, suposem els següents clients que consumeixen els següents valors, en la unitat que vulguin de memòria (KB, MB, MiB, etc):

    10, 15, 150, 5, 7, 10, 11, 12

    La mitjana donaria aprox ~ 30

    I això perquè tenim un extrem (150) molt gran, i que ens disparata els càlculs. La mitjana consisteix a ordenar aquestes dades, dividir la quantitat de mostres per 2 (el nostre centre) i després obtenir el nombre d'aquesta posició. Amb això tindríem alguna cosa com

    5, 7, 10, 10, 11, 12, 15, 150

    Llavors la nostra mitjana seria: 8/2 = 4 o sigui ~ 10

    Aquí es veu, que no importa que tan disbarat pugui ser l'extrem, sempre ens donarà un valor més realista. Si afegim un client que consumeix 200, la nostra mitjana serà 11, mentre que la mitjana potser se'ns vagi a .......

    És només una aportació, i és molt discutible, perquè amb les connexions no es fot.

    Abraçada gent linuxera 🙂

  8.   Carlos va dir

    Hola he tingut un problema en el meu servidor dedicat, i és que cada vegada que s'acosta la quantitat de 250 persones aproximadament en línia, segons el google analytics en temps real, el meu servit com que es col·lapsa i es posa lenta la connexió fins cau la connexió a la pàgina web i mai puja més d'aquesta catidad d'usuaris en línia, però quan veig el rendiment de servidor dedicat que és de 8 GB ram mostra 10% d'ús, el cPU: 5% d'ús i el disc dur en: 1.99 % d'ús.
    Em pots ajudar? no trobo que fer, serà que fent aquests pas és la solució?

    1.    Drassill va dir

      Bones Carles.

      El problema que descrius és molt comú quan no es té el servidor correctament preparat. Probablement teu servidor accepti una quantitat de connexions simultànies molt menor i quan arribi a la xifra de 250 connexions es col·lapsi. Seguint el manual hauries de ser capaç de solucionar el problema, si bé en cas de tenir alguna base de dades en aquest servidor també hauries de optimitzar aquesta base de dades.

      Salutacions.

      1.    Carlos va dir

        Drassill, he fet la configuració que vas esmentar i ha resultat satisfactori, ahir vaig arribar a 280 usuaris en línia i no es va penjar al servidor, m'alegra molt aquest resultat, i també vull fer allò altre que em dius a optimitzar la base de dades, com assoliment això?

    2.    Drassill va dir

      El concepte de base de dades és força obert; no és el mateix fer servir mysql que postgres (per exemple). Òbviament no conec totes les bases de dades; he provat mysql i postgres, i l'augment de les connexions simultànies en aquestes estaria basat en el paràmetre max connections; l'optimització de mysql es realitzaria en /etc/my.conf i caldria canviar (entre d'altres) el paràmetre max connections. Per postgres en canvi, tinc un article al meu bloc que explica com optimitzar-que potser et sigui útil o que pots usar-lo com a referència per a la teva base de dades:

      http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html

      Salutacions.

  9.   Erickson Vasquez va dir

    Hola, quan llanço la primera ordre, em mostra valor 0. Que podria ser?

  10.   Daniel Ojeda va dir

    Moltes gràcies per aquest post.

  11.   Rolando Aguilera Salazar va dir

    Quin bon manual, aquesta informació és part del que vaig buscant… gràcies!

    Però ara, si volgués que quan se superen aquests 250 visitants, el visitant 251 vagi a parar a una pàgina d'espera o cua virtual ho puc fer des d'aquesta mateixa configuració?

    Salutacions i gràcies!