Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 18 de Septiembre de 2.000 - Lunes
References: <NEBBLHOKCLDMMIAGBNBPIEMODMAA.adrian.garcia@chi.es> Message-ID: <39B76334.735B2123@argo.es> Date: Thu, 7 Sep 2000 12:43:16 +0200 From: Jesus Cea Avion <jcea@ARGO.ES> Organization: Argo Redes y Servicios Telematicos - http://www.argo.es/ Subject: Re: Quality of Service To: PROVEEDORES@LISTSERV.REDIRIS.ES
> Hay modulos para limitar la velocidad en Apache (configurables para
Cuidadín con esto.
Si tienes un servidor Apache con poco tráfico, te servirá. Pero si tu servidor web tiene muchos accesos te encontrarás que si limitas el ancho de banda los procesos Apache seguirán "conectados" más tiempo a cada cliente, y te puedes encontrar con que no dispones de suficientes procesos Apache para atender las peticiones.
Ejemplo:
Si tienes 5 accesos por segundo, cada uno de ellos con una media de 5Kbytes, estarás sirviendo unos 25 Kbytes/segundo. Supongamos que tu línea esta dimensionada para 30Kbytes/segundo. El número medio de procesos Apache en uso será de 25*5/30=4.2.
Supongamos ahora que limitamos el ancho de banda a 20Kbytes/segundo. Seguimos teniendo 5 accesos por segundo, pero ahora cada uno de ellos tarda 1.25 segundos en ser procesado. Como cada petición tarda 1.25 segundos en procesarse, y llegan 5 peticiones nuevas por segundos tenemos que:
Usando el sentido común debería ser claro que el número de procesos apache necesarios para servidor todas estas peticiones es... ¡INFINITO!.
En la práctica no se llega a tanto porque el número máximo de procesos apache se configura, pero está claro que llegaremos a ese límite tras unos pocos segundos, y que las peticiones nuevas que entren, tras llenar los procesos y el "backlog" del sistema operativo, sencillamente *SE PIERDEN*.
No hay solución para este problema. Como mal menor, yo suelo poner una caché SQUID delante de un Apache que va a ser sometido a mucha carga, porque el SQUID procesa todas las peticiones en un único proceso de forma muy eficiente (yo he tenido 16380 sesiones SIMULTANEAS con un SQUID "tuned", y detrás un apache con sólo 50 procesos). El SQUID consigue que el Apache complete la petición en muy poco tiempo (milisegundos) aunque la transmisión en sí de la página pueda llevar mucho tiempo. Es decir, el SQUID desvincula la velocidad de recepción del cliente con la velocidad de transmisión del Apache.
Otra ventaja del SQUID es que puede hacer buen uso de las conexiones persistentes, de cara al servidor web. En el ejemplo anterior, yo he llegado a canalizar más de 1000 peticiones web a través de una única conexión SQUID<->APACHE. Y no metía más porque tenía configurado el apache para "reciclar" procesos tras 1000 peticiones, y porque algunas de las páginas solicitadas son "activas" y cortan implícitamente las sesiones "persistentes" (hay formas de evitarlo, pero en en mi experiencia no lo he necesitado, haciendo un uso inteligente de cabeceras como "expires").
Por otra parte, el SQUID también tiene sistema de control de ancho de banda propio.
Tengo pendiente escribir un artículo sobre la combinación SQUID<->Apache desde hace meses. A ver cuando tengo un rato...
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
