Como aumentar as conexións simultáneas en Apache

Hoxe veño falarvos unha vez máis dun dos servizos web máis usados ​​do mundo: o servidor web Apache2.

É un tema do que se falou moitas veces, pero agora veño a falarvos doutra característica a ter en conta con este servizo: O límite de conexións simultáneas. Non importa se temos unha nave básica ou unha nave espacial cun procesador i7 e 32 GB de RAM ...

O límite de conexións simultáneas sempre será o mesmo a menos que tomemos as medidas axeitadas, o que significa que se queremos ter moitas persoas conectadas ao mesmo tempo, non só requiriremos un bo hardware, senón tamén unha boa configuración.

Neste caso, non é necesario instalar nada, todo está baseado en conceptos sinxelos que hai que ter en conta para configurar apache; conceptos que deben estar moi claros antes de querer facer ningún cambio.

apache2_logo

O primeiro que debes pensar é: que capacidade ten o meu equipo? Cantas conexións simultáneas poden soportar o meu equipo se o forzo o máximo posible? Todo isto depende dun único factor; RAM (memoria de acceso aleatorio).

Canto maior sexa a memoria RAM, maior será o número de conexións, aínda que non hai un valor fixo (é dicir, X clientes por cada X RAM), é por iso que antes de nada é importante facer algúns pequenos cálculos no noso servidor web, co para coñecer os nosos límites.

O primeiro que debes saber é canta memoria RAM consume en media cada conexión a Apache, xa que cada conexión establecida supón un determinado consumo de RAM no sistema ... Evidentemente non todas as conexións consumen o mesmo RAM, co que terías que facer un multimedia ... Todo isto pódese obter co seguinte comando:

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

O resultado obtido representaríase en megabytes e pode variar segundo o número de conexións activas, o tipo de páxinas ás que se accede, etc ... Polo tanto, é recomendable realizar a proba con diferentes separadores abertos; cada un deles amosando contido diferente se é posible. No meu caso, por exemplo, o resultado foi 9.5458, que se o redondeamos cara arriba sería 10 MB RAM consumida de media por conexión.

Tamén é importante saber canta memoria RAM consume o resto dos procesos que están activos no sistema, xa que o servizo web non é o único que se executa no sistema operativo e é necesario deixar memoria RAM libre no servidor para que poida executar o resto das tarefas. Isto pódese obter co comando que se mostra a continuación:

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

O resultado obtido tamén se representaría en megabytes e amosaríanos con bastante precisión a cantidade de RAM consumida polo resto dos procesos; no meu caso 800 MB. Con esta información poderiamos facer un cálculo xeral do número de conexións simultáneas que poderiamos ter; Calculo que obteríamos a través dunha operación moi sinxela.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

Con esta fórmula na man, imaxinemos que temos un ordenador con 4 GB de RAM, é dicir, 4096 MB e que o noso ordenador mostrou os resultados mencionados; o cálculo sería:

(4096 - 800) / 10 = 329 conexións simultáneas

O problema deste cálculo é que un é demasiado extremo, xa que consumiría toda a memoria RAM (facendo que o servidor consuma intercambio) e tamén, no caso de ter unha base de datos, como MySQL ou calquera outra, as conexións a ela tamén consumirían memoria RAM. , co cal o número obtido podería cualificarse como un número utópico. Polo tanto, para liberar a memoria para posibles procesos adicionais e tamén considerar a posibilidade de que se executen conexións a unha base de datos, reduciriamos o número de conexións a 250.

Agora que temos o número máximo de conexións simultáneas, teriamos que preparar Apache para recibir este número, o que se fai no ficheiro de configuración desta chamada. apache2.conf, que está aloxado en / etc / apache2.

O ficheiro en cuestión segue unha estrutura baseada en módulos, cada un co seu nome correspondente, pero só nos interesaría un deles, cuxo nome é  mpm_prefork_module. O módulo en cuestión ten os seguintes datos por defecto:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Este módulo ten unha serie de parámetros moi importantes, aínda que hai un deles que nos interesaría especialmente, o chamado MaxClients. Este parámetro especifica o número máximo de conexións simultáneas e debería modificarse a 250.

Un detalle a ter en conta é que cando se especifica un valor distinto ao predeterminado no devandito parámetro, é necesario engadir outro máis ANTES deste. Este parámetro chámase ServerLimit e establece o límite de conexións que o servidor podería "manter" incluso cando está fóra do límite.

O parámetro ServerLimit sempre ten que ser lixeiramente superior ao MaxClients e aquí, como hai pouca marxe de manobra, un límite de 270. Isto faría que o módulo fose así:

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

Agora só sería necesario reiniciar o servizo Apache usando o comando: 

/etc/init.d/apache2 reiniciar

Con isto xa poderiamos gozar do noso servidor web optimizado.

Saúdos.


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

21 comentarios, deixa os teus

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.

  1.   zetatino dixo

    Grazas pola publicación.

    1.    Drassill dixo

      Alégrome de que che resultase útil.

      Saúdos.

  2.   Miguel Angel dixo

    Hai un xeito de agruparse con Apache e dous servidores, ¿podes explicar como funciona?

    1.    Drassill dixo

      Aínda que lin algunha teoría ao respecto, nunca a apliquei á práctica. Aínda así, quizais este artigo poida darche algunhas orientacións ao respecto, aínda que repito que non tiven a oportunidade de poñelo en práctica:

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

    2.    Eduardo Jalil dixo

      Preguntaches moito tempo, se non solucionaches; Teño un esquema de equilibrio cun terceiro que actúa como un sistema de ficheiros, dirixe as carpetas que están en var / www / html / (no meu caso) ao sistema de ficheiros, polo que comparten a mesma información e posiblemente necesite unha ip virtual que responda e redirixir aos IPS dos apaches, para iso podes ocupar un haproxy e se o desexas en alta dispoñibilidade podes integralo keepalive no caso de que un caia, o outro siga respondendo ou tamén se xa tes un dominio para a aplicación, podes equilibrar con libra facendo backends a ambos servidores, para casos específicos como o moodle ou certas aplicacións que se conectan a unha base de datos en mysql, tería que crear un usuario por servidor de aplicacións que apunte á mesma base de datos.

  3.   xamaru dixo

    Moitas grazas pola publicación, tes toda a razón, o RAM é o cálculo principal, aínda que imaxino que tamén calculamos o número máximo de procesos que o noso procesador pode manexar (por suposto, primeiro facendo o cálculo da memoria principal) e como se distribuiría o disco duro (particións de exemplo / var = 1TR).

    1.    Drassill dixo

      Tes razón; todo é importante, como o control de temperatura entre outras cousas. Obviamente un potente procesador pode executar un maior número de tarefas simultaneamente cunha gran eficiencia, pero o obxectivo desta publicación era explicar a importancia da memoria RAM respecto ao número de conexións simultáneas.

      Un bo xeito de controlar todos estes factores e ver se o noso procesador non está saturado ou se temos pouca memoria RAM libre sería empregando un script bash. Quizais sexa interesante para ti este post que fixen hai uns días sobre el, que che deixo no seguinte enlace; É un seguimento global pero pode ser interesante para un:

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

      lembranzas

  4.   Sergio S dixo

    Moi boa nota, moitas grazas!

    1.    Drassill dixo

      Moitas grazas! Espero que o puideses aproveitar.

  5.   pallaso dixo

    Non quero ser un imbécil ...
    ... Pero aumentando o número de conexións non deixas máis vulnerable a un ataque DDoS?

    1.    Drassill dixo

      Non é unha pregunta cretina tranquila. A verdade é que, aumentando o número de conexións simultáneas, fortalecemos en parte a Apache contra os ataques DDOS, xa que hai que ter en conta que o número de conexións simultáneas máximas establecidas no servidor é o número de conexións máximas totais, non as procedentes de un só usuario. Así, aínda que ao principio só podiamos soportar 150 conexións simultáneas (sexan conexións dunha fonte lexítima ou non), agora podemos contar con tantas como o noso servidor admita, requirindo un maior número de conexións ao mesmo tempo para quedar sen servizo. Obviamente, aumentar o número máximo de conexións non é un xeito de protexerse deste tipo de ataques, senón que deben implementarse políticas de firewall. Se, por exemplo, o servizo web que desexa poñer estará exposto a internet, unha medida de seguridade que podería implementarse sería a adición destas liñas ao noso cortalumes:

      iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-upto 10 -m state –state NOVO -j ACEPTAR

      iptables -A INPUT -p tcp –port 80 -m state –state ESTABLECIDO, RELACIONADO -j ACEPTAR

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

      1.    pallaso dixo

        Unha das características dos ataques DDoS é que pode aparecer que un atacante envía paquetes desde varias direccións diferentes, o que impide que o fluxo de paquetes só proceda dunha dirección.

    2.    Drassill dixo

      Tes razón no sentido de que un cortalumes coma o que configurei non é moi eficiente contra un ataque DDOS, xa que provén de diferentes fontes. Aínda así, é mellor limitar o número de conexións a 10 para cada unha destas fontes en lugar de non ter un límite, de xeito que cada fonte poida establecer cen conexións ou máis.

      En calquera caso, o kit da pregunta é que canto máis conexións simultáneas admita o servidor, máis difícil será derrubalo cun ataque DDOS, o que faría máis difícil que un atacante derrubase a páxina.

      Saúdos.

  6.   eliotime3000 dixo

    Bo. Polo de agora continúo con NGINX no meu sitio para non torturar o VPS que teño.

  7.   Bruno cascio dixo

    Boa publicación @ Drassill!

    Quería contribuír con algo quizais máis estatístico que de configuración.
    Aínda que a forma máis sinxela e rápida de calcular o parámetro de consumo é coa media, quizais poderiamos ser máis rigorosos e usar a "mediana" no canto da "media". De que nos salvaría? Que os números se disparan por se unha conexión consumiu moita memoria. Por exemplo, supoña que os seguintes clientes consumen os seguintes valores na unidade de memoria que desexan (KB, MB, MiB, etc.):

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

    A media daría aproximadamente 30

    E isto porque temos un final moi grande (150) e os cálculos son tolos. A mediana consiste en ordenar estes datos, dividir o número de mostras por 2 (o noso centro) e logo obter o número desa posición. Con isto teríamos algo así

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

    Entón, a nosa media sería: 8/2 = 4 é dicir ~ 10

    Aquí podes ver que por moi tolo que poida ser o extremo, sempre nos dará un valor máis realista. Se engadimos un cliente que consume 200, a nosa mediana será de 11, mentres que a media pode ir a .......

    Só é unha contribución, e é moi discutible, porque coas conexións non se atornilla.

    Hug people linuxera 🙂

  8.   Carlos dixo

    Ola, tiven un problema no meu servidor dedicado e é que, cada vez que se achega a cantidade de aproximadamente 250 persoas en liña, segundo Google Analytics en tempo real, o meu servidor cae e a conexión faise lenta ata que cae a conexión ao sitio web e nunca carga máis que ese número de usuarios en liña, pero cando vexo o rendemento do servidor dedicado que ten 8 gb de RAM, mostra o 10% do uso, a CPU: o 5% do uso e o disco duro en: 1.99 % de uso.
    Podes axudarme? Non atopo que facer, ¿facer estes pasos é a solución?

    1.    Drassill dixo

      Bo Carlos.

      O problema que describe é moi común cando o servidor non está preparado correctamente. Probablemente o seu servidor acepte un número moito menor de conexións simultáneas e cando alcance as 250 conexións fallará. Seguindo o manual deberías poder resolver o problema, aínda que se tes unha base de datos nese servidor tamén terías que optimizar esa base de datos.

      Saúdos.

      1.    Carlos dixo

        Drassill, fixen a configuración que mencionaches e foi satisfactoria, onte cheguei a 280 usuarios en liña e o servidor non colgou, estou moi contento con este resultado e tamén quero facer a outra cousa que me digas para optimizar a base de datos, ¿ Como podo conseguilo?

    2.    Drassill dixo

      O concepto de base de datos é bastante aberto; usar mysql non é o mesmo que postgres (por exemplo). Evidentemente non coñezo todas as bases de datos; Probei mysql e postgres, e o aumento das conexións simultáneas nestas basearíase no parámetro max conexións; a optimización de mysql faríase en /etc/my.conf e habería que cambiar o parámetro de conexións máx. (entre outros). No canto dos postgres, teño no meu blog un artigo que explica como optimizalo que pode ser útil para vostede ou que pode usar como referencia para a súa base de datos:

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

      Saúdos.

  9.   Erickson vasquez dixo

    Ola, cando lanzo o primeiro comando, móstrame o valor 0. Que podería ser?

  10.   Daniel Ojeda dixo

    Grazas por esta publicación.