Ya me voy acercando y una vez en el servidor, ¿qué más puede provocar cuellos de botella?. El acceso a los datos.

Ver también:

• Throttling Apache.
• Case study: Optimizando un web server en linux pt. 1.
• Case study: Optimizando un web server en linux pt. 3.

Sistema de archivos

Tras años de jugar en cuanto sistema de archivo existente en Linux, más que benchmarks y anotaciones sagradas tengo experiencias, sesgadas probablemente, pero no menores. Manteniendo un servidor web, donde en promedio cada archivo servido no tiene mas de 100KB de tamaño en disco, es necesario un sistema de archivos que sea eficiente (y estable) con archivos pequeños.

Mi primera tendencia fue a utilizar XFS, pero pesar de su solidez y rapidez, su comportamiento cuando el sistema de archivos se hace cada vez mas granulado comienza a dar problemas, búsquedas en directorios demasiado grandes se hacen cada vez más lentos. ReiserFS entonces fue mi segunda intención, pero tras varios accidentes (si, ya dije que probablemente sesgados) en donde terminé con sistemas inconsistentes, no graves estadísticamente hablando, pero que se corrompa un httpd.conf con cientos de vhosts no es ninguna gracia (como alguna vez me ocurrió), finalmente descarté ReiserFS tal vez tan solo para tener la conciencia limpia, ya que continúo utilizandolo en mis desktop (al igual que los «filmservers» con XFS).

Este no pretende ser un manual de configuración y optimización específico para tu aplicación web, sino más bien un caso de estudio ajustado a mis necesidades específicas. Puedes tomar en cuenta el análisis hecho para sacar tus propias conclusiones. Estará compuesto de varios episodios en donde se toman en cuenta los diversos caminos a tomar.

Reitero esto ya que de seguro «tu kilometraje puede variar».

Ver también:

• Throttling Apache.
• Case study: Optimizando un web server en linux pt. 2.
• Case study: Optimizando un web server en linux pt. 3.

La idea

Tal vez uno de los servicios de mayor uso y expansión a traves de internet sea la web. Y en este ámbito quien se lleva la torta es Apache, quien según Netcraft maneja alrededor del 67% de los sitios web disponibles en la red.

Un dato aparte es que Apache ha tenido durante el 2006 una pequeña baja en su supremacía en favor de otras soluciones web, probablemente por las mismas razones que estoy escribiendo: la busqueda de la mejor performance.

Hay bastantes otros servidores web menos usados pero que logran mayores performances para contenidos particulares. Lighhtpd y su actual relación con la moda Web 2.0 y Ruby on Rails, y servidores principalmente orientados a servir óptimamente contenido estático como Thttpd, Boa (quien sirve el contenido estático de Slashdot, algo no menor) y Tux. Y por último pero no menor, la aparición de el (de esperar) completo reemplazo de Apache, Cherokee, del español Alvaro López.

Es claro entonces el interés por lograr la mayor performance posible, reuniendo el conjunto de tecnologías que lo permita sin ya existir el apego casi religioso a la predilección por Apache.

Por qué cresta hablan tan mal estos periodistas. Durante las transmisiones del incendio del edificio Diego Portales las muletillas abundan y en demasía, al punto de ser asquerosamente despreciables, incómodas y hasta con un dejo de verguenza ajena. Quince veces le conté decir a un periodista “estamos en «lo que es»” …

Y para mis blogescuchas que están medio perdidos, «se estaría consumiendo básicamente lo que es en un principio más bién propiamente tal el ala oriente mayoritariamente del edificio Diego Portales».

Leyendo un post en el blog de Claudio me recordé que hace algún tiempo había utilizado hugin sin lograr muy buenos resultados. Ahora intenté nuevamente y el resultado es bastante mejor sobre una vista panorámica de Chiguayante desde la cima del cerro Manquimávida.

Como siempre, esta va con un abrazo a mi amigo Diego, que siempre disfruta imagenes de nuestra tierra bella.

Hace un par de días, Andrea publicó unos videos de su colección de Plan Z para compartirlos con unos amigos de la Universidad que eran tan fanáticos como ella de Peirano y compañía. Pues como era de esperarse en este mundo global aparecieron «amigos» por todas partes luego de ser publicada su dirección en los foros de «El Antro».

Esto provocó de inmediato un «efecto antro» (efecto slashdot, pero con download accelerator debajo del brazo) en que las malas costumbres de algunos comenzaron a afectar el buen cumplimiento de apache.