Blackhold

Configurando apache para la guerra (alto rendimiento)

Posted on maig 24th, 2010 by admin

Iba a poner en el título alta disponibilidad pero no trata de esto, sino de como configurar el apache de tal forma que pueda servir su contenido de una forma mucho mas eficiente.

Cuando tenemos un servidor apache sirviendo nuestro blog que apenas visitan una decena de personas al día esto no nos tiene que preocupar, pero si tenemos que hacerlo si en este mismo servidor hay un numero mucho mas alto de visitas diarias.

Hace un tiempo me pidieron configurar un apache para alto rendimiento, como no había configurado hasta el momento ninguno no me había preocupado ni siquiera para este tema, pero ahora con la vuelta a la carga con marsupi es necesario tener en cuenta alguna de estas cosas.

En realidad lo que significa configurar un apache para alto rendimiento es primero de todo, saber qué tipo de datos vas a transferir y segundo el ancho de banda y capacidad de hardware de qué dispones.
Al leer este artículo (que tan amablemente trataré de traducir), me quedé perpleja, pensaba que la gran mayoría de las cosas me sonarían a chino, me venía de nuevo a la cabeza la semejanza a un trauma craneoencefálico a un chichón o una gastroenteritis a un dolor de barriga.
La idea es que el sistema pueda recibir muchas visitas sin que se sature ni la memoria ni el ancho de banda, a partir de ello aquí tenéis algunas ideas de por donde empezar.


1. Cargar sólo los módulos necesarios
Es estúpido tener encima de la mesa libros que no vas a usar para el trabajo que estás haciendo, así que lo mejor es sacarlo de ahí, para ello tenemos el comando a2dismod, que desahabilita los módulos que tenemos instalados.
Como anotación, para cargar módulos es con el a2enmod. Estos dos comandos la única cosa que hacen son links simbólicos de /etc/apache2/mods-available a /etc/apache2/mods-enabled.
Para añadir mas módulos basta consultar nuestro gestor de paquetes o la web de apache.

2. Usar los módulos de multiprocesing apropiados
Apache es un servicio que ofrece el servicio creando nuevos procesos para cada una de las tareas a realizar, desde servir una imágen, escribir una línea a log, etc.
En apache hay 2 versiones de multi processing, la worker y la prefork. La worker por ejemplo trabaja a un rendimiento y escalabilidad mucho mayores a la prefork, cada proceso que genera varios procesos hijos, estos son agrupados y permiten usar la misma conexión, esto en contra pero hace que si falla uno de los procesos hijo falla todo el proceso padre, la prefork evita esto, pero es mas lenta ya que cada proceso hijo genera una conexión.

3. DNS lookup
Cada vez que hacemos una conexión a un cliente el apache tiene que resolver el nombre del cliente, esto hace que tenga que hacer una petición al DNS, para accelerar este proceso, apache tiene la posibilidad de crear una lista interna de hosts-ips.
La opción en apache es la HostnameLookups, por defecto viene desactivada desde la versión 1.3 y por esto se recomienda el uso de un programa de post-procesamiento llamado logresolve.

4. AllowOverride
Si no vamos a usar ficheros .htaccess o simplemente si estamos administrando un servidor y no queremos que los usuarios puedan modificar las opciones por defecto de apache, simplemente cuando definamos una sección de directory, especificamos AllowOverride None.
AllowOverride All buscaría en los directorios típicos ficheros de configuración .htaccess, esto lo que hace es que cada vez que se carga una página web vaya a buscar dicho fichero. Así que es recomendable dejarlo siempre deshabilitado a menos que queremos que un directorio tenga un comportamiento especial, como podría ser con el mod_rewrite en los wordpress mu.

5. FollowSymLinks y SymLinksOwnerMatch
Personalmente el SymLinksOwnerMatch ni lo conocía, pero simplemente lo que hace es lo mismo que FollowSymLinks pero que comprueba que el usuario que está ejecutando el proceso de apache puede acceder a aquel directorio.
Esto es una magnífica medida de seguridad pero también consume muchos mas recursos que el FollowSymLinks.
El FollowSymLinks lo que hace es que si en un directorio tienes un vínculo simbólico a otro directorio lo sigue, así que podrías hacer un link simbólico en /var/www llamado música apuntando a tu directorio de música del home y sería como tener la música en el directorio de apache, pero cuidado! hay que estar muy atento de no vincular un directorio que dentro tenga otros directorios con contenido delicado, ya que este también será accesible (importante tener en cuenta el valor Index, que permite hacer un índice del contenido del directorio).

6. Negociación
Otro de los valores interesantes es Multiviews, esto lo que hace es que cada vez que accedes a un directorio escanea el contenido de este, si básicamente vas a acceder a unos ficheros ya vinculados y no tienes por qué saber el contenido de este directorio simplemente esborra la opción Multiviews, ahorrarás al pobre apache de tener que hacer esta misma tarea innecesaria cada vez.

7. MaxClients
MaxClients define el numero de clientes que pueden conectarse, si el numero es demasiado bajo hará que haya muchos timeouts de las conexiones aunque la máquina no se disparará en consumo de RAM, en caso contrario, si el valor es alto apenas se darán timeouts, pero en momentos de mucho tráfico hará que nuestra máquina swapee y acabe funcionando lenta.

Para calcular este valor podemos usar esta fórmula:

MaxClients = Total RAM dedicated to the web server / Max child process size

8. MinSpareServers, MaxSpareServers, y StartServers
Este es similar al anterior pero hace referencia al numero de procesos hijos que puede tener activos un proceso. Dependiendo de la carga de los procesos puede hacer que tarde mas o menos en servir el contenido. Por ejemplo si tenemos una página que se tiene que procesar mucha información, nos va a interesar que use el máximo numero de procesos hijo para resolver el contenido, pero por contra, si definimos este numero muy bajo y el proceso es muy alto va a hacer que se tarde mucho en servir el contenido final.

9. MaxRequestsPerChild
Por defecto está a 0, es decir que no hay límite, pero no se recomienda en servidores con muchas visitas, ya que estas podrían hacer caer el servidor.

10. KeepAlive y KeepAliveTimeout
La directiva KeepAlive, permite hacer varias peticiones sobre la misma conexión TCP. Esto es particularmente útil cuando se están sirviendo páginas HTML con muchas imágenes. Si KeepAlive está en Off, entonces se tiene que hacer una conexión TCP para cada imagen, entonces para evitar esto se pondría el KeepAlive en On.
KeepAliveTimeout define el tiempo que tiene que esperar para la siguiente petición. Se recomienda definir este valor de 2 a 5 segundos, ya que si es demasiado grande, se estaría desaprovechando la posibilidad de ofrecer otro contenido a otro visitante durante la espera.

11. Compresión HTTP y caching
La compresión HTTP está especificada desde la versión 1.1 de HTTP, así que está soportada por todos los navegadores. Esta opción permite disminuir drásticamente el consumo de ancho de banda (según estudios del 75,2%!), pero en su contra consume muchos mas recursos, ya que usa gzip para comprimir el contenido antes de mandarlo.
En apache se puede habilitar la compresión habilitando el módulo mod_deflate.

Con caching lo que se hace es que el contenido ya pedido anteriormente ya esté preparado para servirlo. Para configurar estos valores usamos mod_expires y mod_headers. En versiones anteriores a la 2.2 es necesario habilitar mod_cache, en posteriores esta opción ya viene activada por defecto.

12. Separar el contenido dinámico y el estático
Anda que buena idea! los que administramos apache sabemos que no es lo mismo servir una página HTML puro y duro que una con PHP, por esto que mediante los proxys HTTP podemos decirle al apache que tenemos en el puerto 80 que mande las peticiones de cierto contenido a otro servidor apache que sólo se encargue de servir imágenes, documentos o páginas web estáticas.
Un servidor que ofrece contenido dinámico puede llegar a consumir 20M por proceso, en cambio uno de estático como mucho 1M.
Esto lo podremos hacer mediante los módulos mod_proxy y rewrite_module (comentado antes).

Y hasta aquí algunas de las opciones para tener nuestro apache super maqueadito, analiza primero de todo el tipo de tráfico que va a tener tu servidor y si tienes la posibilidad de tener varios, separa el tipo de servicio que tengan que ofrecer a un mas alto rendimiento.

15 Responses to “Configurando apache para la guerra (alto rendimiento)”

Roger Siadousjuny 3rd, 2010 at 20:14

hola, tengo un servidor dedicado apache con http://www.theplanet.com necesito mejorar la configucion del apache asi como la instalacion de moludos debido a que no me funciona correctamente muchos plugins,componentes, en el joomla.

necesito hacer una evaluación del porque hay plugins y componentes que no funcionan correctamente en mi servidor.

los pullgins y componentes que no funcionan son los relacionados con imagenes, galeria de imagenes, videos, etc

espero que me puedas ayudar.

gracias
roger siadous

Usuario_moodlenovembre 5th, 2012 at 21:42

Hola, Se que ya con lo expuesto aqui esta uno mas que agradecido. Viendo lo mod_proxy entonces podria yo tener un servidor principal con moodle y otro con diferente ip(otro internet) en el cual se enviaran las tareas de alumnos; para asi aprovechar el ancho de banda de los dos internets?

Diego Morettijuny 13th, 2014 at 23:06

otro foco es la optimización de la base de datos, tablas, uso de índices, tamaño de tablas, eliminar escaneo completo en búsquedas con like y similares, etc, y la optimización extrema del peso de imágenes, además del uso de caché

Dan@KenSeifebrer 19th, 2015 at 23:36

Muy grande, tío. Estaba buscando algunas ideas sobre cómo optimizar mi server, pero no esperaba encontrarme tantas y tan bien ordenadas en un solo post. :)

Leave a Response

« »

guy fawkes