Hasta hace algunos años siempre que se hablaba de montar un servidor web rondaba el nombre de Apache y por lo general era la opción inicial, ahora las cosas han cambiado y decidí recopilar información de fuentes confiables, traducirla al español, de por que Apache ya no es la mejor opción, al menos no de la antigua forma.

Apache es un servidor desarrollado en 1995, es una plataforma muy estable diseñada para ser extendida mediante módulos.

Los modulos de Apache lo proveen de muchas funcionalidades, entre ellas la posibilidad de servir contenido dinámico y ello dio paso a el stack XAMPP(Apache, MariaDB[Antes se usaba MySQL], PHP, Perl).

Apache esta diseñado para crear un thread/hilo por cada cliente que necesite ser atendido, este aislamiento ayudo a agilizar el desarrollo y la innovación.

La innovación trajo consigo un gran crecimiento en Internet y los usuarios comenzaron a crecer exponencialmente.

A su vez los componentes de las paginas comenzaron a ser mas y mas pesados y los usuarios menos pacientes al esperar que una pagina web cargue completamente.

Los cambios en el volumen de trafico de usuarios y páginas pesadas comenzaron a ser un desafío al modelo de un thread/hilo por usuario que tanto ayudo a Apache en un principio.

Sumado a eso comenzó a extenderse una practica llamada HTTP keepalive que permite disminuir el tiempo de carga de una página haciendo peticiones paralelas de los recursos, cada petición abierta es atendida por un proceso httpd, por esta razón Apache necesita crear numerosos procesos largos.

Para mejorar la portabilidad y escalabilidad en algunas plataformas, los principales desarrolladores de Apache crearon dos modelos de procesamiento adicionales (denominados módulos multiprocesamiento o MPM).

El MPM reemplazó los procesos separados de httpd con un pequeño número de procesos secundarios que ejecutaban múltiples subprocesos de trabajo y asignaban un subproceso por conexión. Esto fue útil en muchas versiones comerciales de Unix (como el AIX de IBM) donde los hilos son mucho más ligeros que los procesos, pero es menos efectivo en Linux donde los hilos y procesos son solo encarnaciones diferentes de la misma entidad del sistema operativo.

Más tarde, Apache añadió el event MPM, que amplía el MPM añadiendo un hilo escucha independiente que gestiona las conexiones de mantenimiento de inactividad una vez que la solicitud HTTP se ha completado.

Estas medidas sirven para mejorar el rendimiento, pero el modelo monolítico de un solo servidor que fue clave para el éxito temprano de Apache ha seguido luchando a medida que aumentan los niveles de tráfico y las páginas web se vuelven más y más pesadas.

El modelo pesado y monolítico de Apache tiene sus límites

El desempeño en los benchmarks de laboratorio a menudo no se reproduce en implementaciones de producción en vivo en sitios web ocupados y el ajuste de Apache para hacer frente al tráfico del mundo real es un arte complejo. De forma poco equitativa, Apache ha ganado una reputación como un servidor web hinchado, excesivamente complejo y limitado al rendimiento que puede ser explotado por ataques lentos de denegación de servicio (DoS).

Hasta aquí podemos saber un poco de historia de Internet como funcionan muchos de los servidores creados a día de hoy, ya que muchos utilizan Apache como base, sus problemas así como sus soluciones.

Introducción a NGINX - Diseñado para alta concurrencia

NGINX fue escrito específicamente para abordar las limitaciones de rendimiento de los servidores web Apache.

Fue creado en 2002 por Igor Sysoev, un administrador de sistemas para un popular sitio ruso (Rambler.ru), como una solución escalable para ayudar al sitio a administrar mayores y mayores volúmenes de tráfico.

Se convirtió en opensource en octubre de 2004, en el 47 aniversario del lanzamiento de Sputnik.

NGINX puede ser desplegado como un servidor web independiente, y como un proxy de frontend para Apache y otros servidores web.

Esta solución de despliegue actúa como un dispositivo de descarga de red frente a los servidores Apache, traduciendo las conexiones lentas del lado de Internet en conexiones rápidas y confiables del lado del servidor, y descargando completamente las conexiones keepalive de los servidores Apache.

El efecto neto es restaurar el rendimiento de Apache a niveles cercanos a los que los administradores ven en un punto de referencia local.

NGINX también actúa como un amortiguador de choque, protegiendo a los servidores vulnerables de Apache de picos en el tráfico y de ataques de conexión lenta como Slowloris y slowhttprequest.

El secreto en la arquitectura

El rendimiento y la escalabilidad de NGINX surgen de su arquitectura basada en eventos. Difiere significativamente del enfoque de proceso o hilo por conexión de Apache, en NGINX, cada proceso de trabajo puede manejar miles de conexiones HTTP simultáneamente. Esto resulta en una implementación considerada altamente como ligera, escalable y de alto rendimiento.

Para muchos tipos de aplicaciones, NGINX y Apache se complementan bien, por lo que suele ser más apropiado hablar de "NGINX y Apache" en lugar de "NGINX vs. Apache". Un patrón de inicio muy común es desplegar el software NGINX de código abierto como proxy (o NGINX Plus como plataforma de entrega de aplicaciones) frente a una aplicación web basada en Apache. NGINX realiza el levantamiento pesado relacionado con HTTP: sirve archivos estáticos, almacenamiento en caché de contenido y descarga de conexiones HTTP lentas, para que el servidor Apache pueda ejecutar el código de la aplicación en un entorno seguro.

NGINX proporciona todas las características principales de un servidor web, sin sacrificar las cualidades ligeras y de alto rendimiento que lo han hecho exitoso, y también puede servir como un proxy que reenvía las solicitudes HTTP a servidores web ascendentes (como un backend de Apache) y FastCGI, memcached, SCGI y uWSGI.

NGINX no busca implementar la enorme gama de funcionalidades necesarias para ejecutar una aplicación, sino que depende de servidores especializados de terceros como PHP-FPM, Node.js e incluso Apache.

“Apache is like Microsoft Word. It has a million options but you only need six. NGINX does those six things, and it does five of them 50 times faster than Apache.” — Chris Lea

Como podemos ver NGINX es un proyecto enfocado en la alta disponibilidad de los servicios, pero se enfoca en servir contenido estático y hacerla de proxy/conector entre otros servidores para darles mayor seguridad y ayudar a manejar el enorme trafico de usuarios.

Actualmente NGINX es utilizado por empresas como WIX, Wordpress y la NASA.

Es posible utilizar el soporte comunitario total mente gratis y también se tienen tres niveles de soporte de paga profesional ofrecido por NGINX, Inc.:

Básico ($1,900 US / year): Para los despliegues no críticos de NGINX en los que los tiempos de respuesta más largos son aceptables y no se requieren revisiones en caliente para implementaciones de producción.

Profesional ($3,000 US / year): Para el despliegue de producción de NGINX y NGINX Plus, o donde se requiera el manejo de casos prioritarios.

Enterprise ($4,500 US / year): Para despliegues de misión crítica de NGINX o NGINX Plus que requieren el nivel más alto de soporte con tiempos de respuesta más rápidos y soluciones a través de consultas telefónicas o web.

¿Qué cubre el soporte comercial de NGINX?

El uso de NGINX opensource y NGINX Plus

Búsqueda y corrección de errores.

Actualizaciones de software.

Asistencia con la instalación.

Notificaciones de seguridad.

Discrepancias en la documentación.

Conclusión:

Como podemos ver Apache como tal no esta muerto y no quiere decir que tengamos que dejar de utilizarlo y utilizar siempre NGINX, de hecho se recomienda utilizarlo junto con.

Simplemente es necesario combinarlo con los nuevos proyectos que están enfocados a solucionar problemas muy específicos en los cuales Apache o cualquier otro servidor no son buenos, en este caso NGINX, tiene los problemas más comunes de Apache resueltos pues así fue como nació.

También podemos ver que se tiene un soporte comercial y denota mucha madurez en el proyecto ya que es una empresa constituida y no es un proyecto que de la noche a la mañana pueda desaparecer, ver el peso y renombre de sus clientes da mucha confianza en ellos.

Fuentes:

https://www.nginx.com/blog/nginx-vs-apache-our-view/