Similitudes entre Apache y una txozna en la Aste Nagusia bilbaina

La semana pasada estuve en la semana grande bilbaina, posiblemente, las mejores fiestas de todo el territorio nacional. Mis incursiones etílicas nocturnas han coincidido con unos cuantos problemas en el servidor en el que se alberga nvivo.es, y la nueva configuració aplicada al mismo me ha hecho reflexionar sobre unas coincidencias que tal vez ayuden a algunos webmasters a optimizar sus servidores web.

Y es que el funcionamiento de un servidor Apache y el funcionamiento de una barra de bar o una barra de txozna son muy similares, y cuentan con los mismos parámetros para configurar.

Uno de los parámetros más importantes es MaxClients, que indica hasta cuantos procesos hijos del servidor web se van a arrancar para servir peticiones de los clientes. Esto no es sino el número de camareros que están sirviendo en la barra de tu bar o txozna.

Si este parámetro es bajo, y llegan avalanchas de peticiones a tu servidor, las nuevas peticiones no pueden ser atendidas y se irán encolando, si las peticiones no bajan de frecuencia, llegará un momento en el que la percepción del cliente web es que no se sirven peticiones, ya que los tiempos de espera se harán eternos. Si el parámetro es muy alto, tendremos más procesos para atender peticiones, pero corremos el riesgo de saturar al servidor utilizando la totalidad de la memoria disponible. En la barra ocurre lo mismo: Si ponemos pocos camareros y tenemos la afluencia de las fiestas de Bilbao, resulta prácticamente imposible hacerse con una triste cerveza, y nuestra sensación es que esa barra no está sirviendo adecuadamente. En cambio, si ponemos muchísimos camareros, como el espacio en la barra es limitado, se molestarán unos a otros en ese pequeño espacio por lo que tampoco atenderán adecuadamente.

Mucha gente no entiende muy bien el KeepAlive del Apache. Este parámetro sirve para que un mismo proceso se encargue de servir todas las peticiones de un documento HTML. Si vamos a descargar un HTML, este además contendrá imágenes, ficheros Javascript, hojas de estilo, etc. Hacer todas estas peticiones a diferentes procesos Apache ralentiza la carga del documento, con el KeepAlive activado, estas peticiones muy seguidas las sirve el mismo proceso. Para comprender correctamente la situación de un KeepAlive desactivado, es como si llegas a una barra con una lista de peticiones de tus colegas (3 cubatas, 4 cervezas, 2 kalimotxos…) y le pides cada trago a un camarero diferente. ¿absurdo, verdad? Aquí radica la importancia del KeepAlive. Pero ¡OJO!. Este parámetro tiene otros asociados, como son el máximo número de peticiones seguidas que te dejará hacer y el tiempo que esperará hasta que considere que has dejado de hacer peticiones. O sea, que un camarero no te va a servir 40 copas ni te va a esperar a que acabes la primera ronda para ponerte la segunda.

Otra particularidad de las txoznas de Bilbao es que el número de camareros varía con el tiempo, al mismo modo que los procesos del servidor Apache, arrancan con un número mínimo (Startservers), se van añadiendo nuevos conforme aumenta la demanda hasta un máximo (MaxClients), tenemos unos cuantos preparados para actuar (MinSpareServers y MaxSpareServers, y si no hay ninguna petición en un tiempo determinado (Timeout), desaparecen sin dejar rastro.

Ya véis, las particularidades de la vida diaría nos permiten comprender mejor las dificultades de nuestra vida profesional, y si el año que viene tenéis oportunidad de acercaros a Bilbao en semana grande (empieza el primer Sábado después del 15 de Agosto) comprobaréis de que os hablo y veréis in situ lo mal configuradas que están algunas txoznas.

Otros artículos sobre optimización de Apache:

http://mnm.uib.es/gallir/posts/2006/09/26/819/

http://www.inkilino.com/2007/07/23/optimizar-apache-en-un-servidor-dedicado/

http://phplens.com/lens/php-book/optimizing-debugging-php.php

El Desafío de FrameWars: PHP Symfony vs Ruby On Rails

Estamos hablando del lenguaje Ruby, y del culpable de su éxito, el framework para desarrollar aplicaciones web, Ruby On Rails.
Este es el blog de un fanático del desarrollo web. He desarrollado en muchos ASP.NET, Perl, J2EE pero sobre todo PHP. Siempre ha sido mi preferencia de cada a realizar proyectos por incontables razones. Por eso asistía desde la distancia a todo el ‘zumbido’ que se estaba gestando en la blogosfera acerca del lenguaje Ruby, del Ruby On Rails, de sus bondades y facilidad de cada al desarrollo.

Debido a la curiosidad innata que sufro y a que todavía soy joven y tengo ganas de aprender cosas nuevas hizo que la semana pasada me acercada por la Conferencia Rails 2006, en Madrid. La verdad es que salí con ganas y dispuesto a meterle mano al lenguaje y al FrameWork.

A este hecho se une que uno de los proyectos en los que trabajo en PHP está llegando a lo que podríamos llamar programación ‘incomoda’ y necesita de un FrameWork en condiciones. Después de rebuscar bastante, me entero de que Yahoo ha desarrollado Yahoo! Bookmarks en PHP, utilizando un Framework llamado Symfony, que coge muchas ideas de Rails en mi lenguaje preferido.

Estos 2 hechos han encendido una pequeña bombilla en mi cabeza, y me he puesto manos a la obra y aquí tienes mi idea, proyecto y desafío personal: FrameWars. El desafío consta en realizar un proyecto web, pero con 2 frameworks diferentes: PHP Symfony y Ruby on Rails. Alguno podría pensar que en realidad se trata de 2 proyectos pero como la funcionalidad debe ser exactamente igual en ambos, lo contaremos como un único proyecto. El objetivo de todo esto: Realizar una experiencia más o menos objetiva con ambos lenguajes y frameworks, y ya de paso, aprender Ruby, Rails, y Symfony

En próximas entradas os comentaré las reglas del desafío y más detalles sobre el mismo.