Evolución de LAMP

Hace ya más de 10 años que surgió la pila de programación web denominada LAMP en honor de las siglas que formaban los 4 principales elementos que conforman esta tecnología: Linux, Apache, MySQL y PHP. Hay otros que intercambiaron las páginas hechas en PHP por Python o incluso por Perl, pero no fueron tan populares y terminaron por dar paso a frameworks que hacían mejor ese trabajo, como por ejemplo Django en Python y Catalyst en Perl.

En los últimos años, el cambio de la web de simple y mero transmisor de información se tornó en una forma de dialogar con otras miles de personas a través de redes sociales, foros e incluso chats. La información ya no era tan solo de lectura para la web, sino que la escritura y lectura se realizaba a partes iguales. Esto hizo que la plataforma LAMP tuviese algunos problemas.

Linux

En su concepción, Linux se vió como un gran sistema operativo, los fabricantes comenzaron a incluirlo como opción para proporcionar software a nivel de servidor y muchos profesionales aportaban código al kernel para tener soporte a todos los niveles. Hay muchos comentarios sobre qué sistemas funcionan mejor en qué núcleos, según esta gráfica, MySQL se ejecuta con mejor rendimiento en FreeBSD:

Pasa lo mismo con SQLite:

Pero todo depende de la versión del núcleo de cada uno y el software que se pruebe.

MySQL

MySQL fue diseñado con la velocidad en mente. Eso hizo que no se tuviesen en cuenta estrategias como MVCC, sino solo métodos de escalado basados en la forma maestro/esclavo, que permiten acelerar las lecturas, pero agrega pérdida en rendimiento para las escrituras y solo se pueden realizar al maestro.

MySQL ha evolucionado mucho desde estas primeras versiones en las que solo se permitían estas estructuras. Además de MyISAM agregó otros engines que le proporcionaban o mayor velocidad y escalabilidad (NDB) o mayor soporte relacional (InnoDB), pero el principal problema se incrementaba cuanto mayor era el tamaño de la base de datos:

Incluso en base a concurrencia, MySQL tiene peor rendimiento que otras como PostgreSQL, por lo que su nivel de escalado deja bastante que desear:

Si el entorno web que vamos a desarrollar requiere el empleo de tantas escrituras como lecturas y/o preveemos que el tamaño de las tablas crezca más allá del millón de tuplas, MySQL no es una opción fiable. En caso de elegirla tendremos que prepararnos para realizar particiones lógicas de tablas (en caso de tablas de gran tamaño), sistemas de caché como Memcache y optimizar el número de consultas lanzadas al sistema.

Apache

El servidor web Apache es el más completo en el mundo del software libre, es el que más características reune teniendo un gran número de módulos para PHP, Python, Perl, Lua, Tomcat, SVN, WebDAV, etc. Hay mucha gente que considera, no obstante, que Apache es un servidor muy pesado y desfasado. Proyectos como el de Cherokee de Álvaro López Ortega dejaron en entredicho el rendimiento de Apache.

Más recientemente, el servidor web Nginx comenzó a tomar protagonismo por su verdadera modularidad y alto rendimiento. A día de hoy es el servidor más empleado como front-end de servicios web. Por tanto, se considera una mejor elección que Apache en muchos aspectos.

PHP

El lenguaje de programación PHP surgió como un nuevo lenguaje de marcas, que permitía agregar código entre las marcas y generar páginas dinámicas con un código simple basado en el lenguaje más conocido hasta la fecha: C.

En la pila LAMP, PHP se emplea como módulo de Apache y se lanza dentro de este cada vez que una página es solicitada. Para las webs de hace 10 años esto era bastante trivial y cómodo. La ejecución de un programa PHP no dura más de lo que tarda en procesar el código de la página solicitada y retornar el resultado a la petición. Es decir, se instancia el código, se ejecuta, retorna el resultado y muere. Si se quiere una cierta persistencia, como una sesión de usuario, se agrega un fichero en el servidor o una entrada en una base de datos y se almacena allí la información que el código va depositando en cada ejecución o tomando si la requiere.

No obstante, la programación web ha cambiado. Desde que AJAX surgió, la peticiones son más constantes y más atómicas lo que requiere mayor rendimiento. Además con la salida de técnicas como websockets, PHP se va quedando cada vez más limitado. Este lenguaje no fue creado para la ejecución de tareas en background y, aunque hay soluciones pensadas para ello, no dejan de ser pequeñas chapuzas que agregan mayor necesidad de memoria, CPU y van mermando la capacidad de procesamiento de la máquina servidora.

Lenguajes como Ruby y Python salieron adelante con frameworks que mantenían parte del procesamiento del código siempre activo, mejor tratamiento de las sesiones y mayor facilidad para el programador. Rails propone muchas soluciones a estos problemas al igual que Django. No obstante, el framework ChicagoBoss se va destacando por su mayor rapidez en la renderización de plantillas.

Nuevas Pilas

Tras la explosión LAMP, está claro que agregando nuevos elementos podemos ir adaptándonos a las nuevas tecnologías que van surgiendo. De cara a servidor, podemos emplear pilas como:

  • Linux + Apache + MySQL + PHP + Memcache, para intentar acelerar no solo el acceso a datos sino también la propia caché de partes de la página que sea costosas de procesar. Almacenando bajo una clave la generación de un bloque de menú, por ejemplo, haciendo que no se tenga nada más que solicitar a memcache y soltar hacia el cliente web.
  • BSD + Ngnix + PostgreSQL + PHP-FPM, esta pila es la que considero más escalable. Además de que la conexión entre Nginx y PHP con FPM es más escalable, Nginx gesiona mejor las conexiones y consume menos recursos, BSD gestiona mejor las conexiones y la memoria y PostgreSQL mantiene un buen nivel de respuesta sea cual sea la proporción de lecturas frente a escrituras.
  • BSD + ChicagoBoss + Riak, esta pila es la más escalable que podemos encontrar. ChicagoBoss es un framework que no solo nos permite la programación de páginas dinámicas, sino también de websockets. La base de datos Riak al mismo tiempo nos facilita el almacenamiento rápido de la información y su escalabilidad. A esta pila se le puede agregar incluso un Nginx para el procesado de los elementos estáticos, pero no es realmente necesario.

Conclusiones

Con lo dicho anteriormente no quiero decir que la pila LAMP sea errónea o mala para el desarrollo web, ni mucho menos, se ha demostrado que funciona. Pero también se ha demostrado que en ciertas ocasiones hay que sacar ingenio para solventar algo que LAMP de por sí no puede solucionar. Pero si agregamos una nueva pila como la segunda propuesta, las necesidades para escalar se verán reducidas drásticamente así como los problemas derivados del rendimiento, sobretodo ante picos de carga.

La solución de ChicagoBoss es la que cada vez más gente está adoptando por ser una solución en la que no hay que preocuparse tanto de la escalabilidad. Hay que hacerla y configurarla, como en todos los demás frameworks y pilas de soluciones, pero está preparado para ello y es relativamente más fácil.

Lo único que queda es abrir la mente y adoptar soluciones que se adapten a nuestros problemas y no a nuestro conocimiento. Solucionar un problema aprendiendo algo nuevo es más reconfortante que intentar crear parches quedando esa sensación de, ¿cuánto aguantará antes de romperse otra vez?