O-tanjoubi omedetou gozaimasu, Feliz cumpleaños a mi. Se ve de cerquita el cambio de folio, wow. Qué estaría pensando en esos momentos, hace como tunmil años cuando hacía solo 3 meses que conocía este mundillo?.

El jueves estuve en la titulación de mi prima-gemela-casi-hermana. Por fin se tituló de Arquitecta (si, sale largo el camino) y a su lado estaba mi primo-casi-hermano ya egresado de sicología. Pensaba yo en el «Valito», su nombre karma, cuando siendo el primo chico del grupo era el regalon siempre con sus genialidades de Batman y superhéroes inventados, y ahora Sicólogo.

Luego de revisar las variables posibles de pobre desempeño a nivel más bajo, me acerco a la optimización del software. Vuelvo a reiterar que «Your mileage may (and will) vary», debido a que mis requerimientos son muy específicos respecto al software servido.

Ver también:

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

Ahora, Apache

Tras mejorar las variables más comunes de posibles cuellos de botella que sean en parte culpables por el rendimiento, llegamos al servidor mismo.

Elección de MPM

Como ya antes fue enunciado, Apache tiene principalmente tres modelos de funcionamiento, siendo mayoritariamente utilizados los modelos de Prefork y Worker. Prefork es tal cual el modelo antiguo de apache 1.3, es decir un proceso por cliente y sin hilos. Worker es un modelo de multihilos en donde algunos procesos manejan distintos clientes mediante diferentes hebras. Debido al costo de cambio de contexto de los procesos en prefork, worker desde ese punto de vista provee un mayor desempeño. El problema asoma cuando utilizamos software que no tenga un suficientemente elaborado sistema de manejo de seguridad de memoria en el ambito de los hilos (o «Thread Safe»), como es el problema de PHP y su TSRM.

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).