Apache vs NGINX - ¿Quién GANA en términos de rendimiento?

Apache vs NGINX es uno de los debates más candentes que existen (desde el lanzamiento de NGINX) porque ambos son uno de los servidores web más comunes en el mundo seguido de LiteSpeed ​​y OpenLiteSpeed.

Apache y NGINX impulsan casi el 60% de los sitios web del mundo. Apache vs NGINX son similares en términos de rendimiento y características. Su arquitectura, seguridad y rendimiento, por otro lado, son todos diferentes.

Puede ser difícil seleccionar entre estos dos servidores porque ambos son excelentes. Debido a que cada servidor web tiene su propio conjunto de ventajas y desventajas, es fundamental elegir la mejor opción posible.

También puede consultar el debate entre openlitespeed y nginx aquí.

Comparación de velocidad de Apache y NGINX

Antes de profundizar en el debate Apache vs NGINX. Primero haremos una prueba de velocidad simple, donde realizaremos pruebas en los siguientes escenarios.

• Probemos un pequeño archivo estático de 5 KBytes
• Archivo estático de tamaño 1MB
• Probando una simple aplicación PHP Hello World
• Evaluación comparativa de Apache vs NGINX para WordPress

Hemos usado el mismo procedimiento para probar openlitespeed vs nginx. OpenLiteSpeed ​​es realmente una excelente alternativa a NGINX porque también admite reglas básicas de reescritura de .htaccess , por lo que puede pasar fácilmente de Apache a OpenLiteSpeed.

Probemos un pequeño archivo estático de 5 KBytes

Veredicto final : ambos servidores realizaron lo mismo con un pequeño archivo estático.

apache

NGINX

Archivo estático de tamaño 1MB

Veredicto final : NGINX claramente ganó con un gran archivo estático.

apache

NGINX

Probando una simple aplicación PHP Hello World

Veredicto final : ambos servidores funcionaron igual con la aplicación php hello world.

apache

NGINX

Evaluación comparativa de Apache vs NGINX para WordPress

Veredicto final : NGINX claramente ganó con un sitio de WordPress. Puede usar esta guía para acelerar su tienda WooCommerce

apache

NGINX

Resultado de la prueba - Apache vs NGINX

Como podemos ver en las pruebas, NGINX es relativamente mejor que Apache en términos de velocidad. Los resultados son:

1. Pruebe un pequeño archivo estático de 5 KBytes:

En esta prueba, vemos que tanto Apache como NGINX están dando relativamente los mismos resultados.

2. Pruebe un archivo estático grande de 1 MB:

En esta prueba, vemos que la velocidad de NGINX es mucho mejor que la de Apache. NGINX está dando un tiempo de respuesta promedio mucho menor.

3. Pruebe una sencilla aplicación PHP Hello World

En esta prueba, vemos que tanto Apache como NGINX están dando relativamente los mismos resultados.

4. Prueba de Apache vs NGINX para WordPress

En esta prueba, vemos que el tiempo de respuesta promedio de NGINX es mucho menor que el de Apache, lo que le da una velocidad mayor que la de NGINX.

apache

Existe una comunidad de desarrolladores que mantienen Apache como un servidor web de código abierto. Utiliza una arquitectura basada en procesos donde crea un nuevo hilo para cada solicitud de conexión.
Además, Apache ofrece una variedad de módulos que pueden usarse para aumentar la funcionalidad de su servidor web. Apache es rápido, confiable, seguro y altamente personalizable para satisfacer las necesidades de diferentes entornos mediante el uso de extensiones y módulos.

Arquitectura de manejo de conexiones

Apache tiene una serie de módulos de procesamiento múltiple (llamados MPM por Apache) que controlan cómo se manejan las solicitudes de los clientes. Esencialmente, esto permite a los administradores cambiar rápidamente la arquitectura de manejo de conexiones.

• mpm-Prefor: este módulo de procesamiento múltiple (MPM) implementa un servidor web previo a la bifurcación que no tiene subprocesos. Cada proceso del servidor puede responder a las solicitudes entrantes y el tamaño del grupo de servidores es administrado por un proceso principal. Es adecuado para sitios que necesitan evitar subprocesos para trabajar con bibliotecas que no son seguras para subprocesos. También es el mejor MPM para aislar cada solicitud, asegurando que un problema con uno no afecte a los demás.
• mpm-worker: este módulo de procesamiento múltiple (MPM) implementa un servidor híbrido de múltiples procesos y múltiples subprocesos. Puede atender una gran cantidad de solicitudes con menos recursos del sistema que un servidor basado en procesos, ya que utiliza subprocesos para entregar las solicitudes. Al mantener numerosos procesos disponibles, cada uno con muchos subprocesos, conserva gran parte de la estabilidad de un servidor basado en procesos.
• mpm-event: el evento Módulo de procesamiento múltiple (MPM) está diseñado para permitir que se atiendan múltiples solicitudes al mismo tiempo al delegar cierto procesamiento a los subprocesos de escucha, liberando los subprocesos de trabajo para atender nuevas solicitudes.
  Apache tiene un diseño flexible que le permite elegir entre una variedad de algoritmos de conexión y manejo de solicitudes. Dado que el panorama de Internet ha cambiado, las opciones presentadas son principalmente un producto de la evolución del servidor y la mayor demanda de simultaneidad.

Contenido estático vs. dinámico

El contenido estático puede ser manejado por servidores Apache utilizando sus mecanismos estándar basados ​​en archivos. Los enfoques de MPM mencionados anteriormente son los principales responsables de la realización de estos procedimientos.

Apache también puede procesar contenido dinámico al incluir un procesador específico del idioma en cada una de sus instancias de trabajo. Esto le permite ejecutar contenido dinámico sin el uso de componentes externos dentro del servidor web. Se pueden usar módulos cargables dinámicamente para habilitar estos procesadores dinámicos.

Debido a que Apache puede manejar contenido dinámico internamente, la configuración del procesamiento dinámico suele ser más sencilla. Los módulos se pueden intercambiar fácilmente si cambian los requisitos de contenido y no es necesario coordinar la comunicación con una pieza de software adicional.

Configuración distribuida frente a centralizada

Al analizar e interpretar las directivas en archivos ocultos dentro de las propias carpetas de contenido, Apache agrega una opción para permitir una configuración adicional por directorio. Los archivos .htaccess son el nombre de estos archivos.

Debido a que estos archivos se encuentran dentro de las carpetas de contenido, Apache busca un archivo .htaccess en cada componente de la ruta al archivo solicitado y aplica las directivas que se encuentran allí. Esto habilita efectivamente la configuración del servidor web descentralizado, que se usa comúnmente para reescrituras de URL, limitaciones de acceso, autorización y autenticación, e incluso políticas de caché.

Si bien todos los ejemplos anteriores se pueden configurar en el archivo de configuración principal de Apache, los archivos .htaccess brindan una serie de ventajas. Primero, debido a que se evalúan cada vez que se encuentran a lo largo de una ruta de solicitud, se implementan sin necesidad de recargar el servidor. En segundo lugar, permite a los usuarios sin privilegios controlar partes específicas de su propio contenido web sin otorgarles autoridad total sobre el archivo de configuración.

Ciertos programas web, como los sistemas de administración de contenido, ahora pueden personalizar fácilmente su entorno sin necesidad de acceder al archivo de configuración central. Los proveedores de alojamiento compartido utilizan esto para mantener el control de la configuración central mientras ofrecen a los clientes acceso a sus directorios específicos.

Interpretación basada en archivos frente a URI

Apache puede interpretar una solicitud como un recurso de sistema de archivos físico o un destino URI que requiere una evaluación más abstracta. En general, Apache usa bloques <Directory> o <File> para el primero, mientras que los bloques <Location> se usan para recursos más abstractos.

Debido a que Apache se creó desde cero para ser un servidor web, interpreta las solicitudes como recursos del sistema de archivos de forma predeterminada. Para encontrar un archivo real, comienza con la raíz del documento y agrega la parte de la solicitud después del host y el número de puerto. En la web, la jerarquía del sistema de archivos está esencialmente representada por el árbol de documentos disponible.

Cuando la solicitud no coincide con el sistema de archivos subyacente, Apache ofrece varias opciones. Una directiva Alias, por ejemplo, se puede usar para mapear a un lugar diferente. El uso de bloques <Location> en lugar del sistema de archivos le permite trabajar directamente con el URI. Las variaciones de expresiones regulares también están disponibles para aplicar la configuración de manera más flexible en todo el sistema de archivos.

Aunque Apache puede funcionar tanto en el sistema de archivos subyacente como en el espacio web, prefiere usar técnicas de sistemas de archivos. Algunas de las decisiones de diseño reflejan esto, como el uso de archivos .htaccess para la configuración por directorio.

Módulo

El sistema de módulos en Apache le permite cargar y descargar módulos dinámicamente para satisfacer sus necesidades mientras el servidor está en ejecución. El núcleo de Apache siempre está presente, pero los módulos se pueden habilitar o deshabilitar, agregando o eliminando funcionalidades y conectándose al servidor principal.

Apache utiliza esta característica para una amplia gama de tareas. Debido a la madurez de la plataforma, viene con una gran biblioteca de módulos. Mod php, por ejemplo, incorpora un intérprete de PHP en cada trabajador en ejecución y puede usarse para cambiar partes de la funcionalidad esencial del servidor.

Por otro lado, los módulos no solo manejan contenido dinámico. Pueden reescribir direcciones URL, autenticar clientes, fortalecer el servidor, registrar, almacenar en caché, comprimir, proxy, restringir la velocidad y cifrar datos, entre otras funciones. Pueden ofrecer una funcionalidad mejorada sin agregar mucho trabajo.

Soporte, Compatibilidad, Ecosistema y documentación

Debido a que Apache existe desde hace tanto tiempo, hay mucho soporte para él. Para el servidor central y las situaciones basadas en tareas que involucran la conexión de Apache a otro software, hay una biblioteca sustancial de documentación de origen y de terceros accesible.

Muchas herramientas y proyectos web contienen herramientas para iniciarse dentro de un entorno Apache, además de documentación. Esto se puede proporcionar en los propios proyectos o en los paquetes que mantiene el equipo de empaque de su distribución.

Por su cuota de mercado y el tiempo que ha estado disponible; Apache recibirá más apoyo de proyectos de terceros en general. También es más probable que los administradores hayan trabajado con Apache, no solo por su uso generalizado, sino también porque muchas personas comienzan sus carreras en entornos de alojamiento compartido, donde Apache se usa prácticamente únicamente debido a las características de administración distribuida de .htaccess .

Ventajas de Apache frente a NGINX

Muchos webmasters y desarrolladores prefieren Apache a NGINX porque es mucho más antiguo. Es compatible con los sistemas operativos Windows, Unix y Linux.

• Para servir material dinámico, este es un excelente desempeño.
• Carga y descarga dinámica de módulos.
• Proporciona un archivo .htaccess por directorio que se puede usar para anular la configuración de todo el sistema.
• El soporte y la documentación son sobresalientes.
• El modelo utiliza un enfoque de una conexión por proceso.
• Incluye los módulos mod_evasive y mod_security, que añaden una capa extra de seguridad.

Desventajas de Apache vs NGINX

• No se puede manejar una gran cantidad de solicitudes al mismo tiempo.
• En comparación con NGINX, lleva más tiempo mostrar contenido estático.
• Proporciona amplias capacidades de configuración y administración. Como resultado, no es apropiado para principiantes.
• Los sitios web con mucho tráfico tienen problemas de rendimiento.

NGINX

En un intento por superar el problema "C10k", el codificador ruso Igor Sysoev inventó NGINX. Igor cumplió su objetivo: NGINX puede administrar fácilmente más de 10 000 conexiones simultáneas. Para manejar mejor las nuevas conexiones, NGINX tiene un diseño asincrónico y basado en eventos. NGINX es un servidor web que ofrece muchas capacidades. A continuación se enumeran algunos de ellos:

• Un caché HTTP y un balanceador de carga
• Proxy front-end de Apache y otros servidores web.
• Este servidor proxy inverso sirve los protocolos HTTP, HTTPS, SMTP, POP3 e IMAP.

Desde su lanzamiento, NGINX ha ganado popularidad debido a su bajo uso de recursos y su capacidad para escalar de manera efectiva en hardware de bajo costo. NGINX es un servidor web que se especializa en servir material estático rápidamente y está diseñado para reenviar solicitudes dinámicas a software que se adapta mejor a tales tareas.

Arquitectura de manejo de conexiones

NGINX llegó a la escena después de Apache, con una mejor comprensión de los problemas de concurrencia que enfrentarían los sitios a escala. NGINX se creó desde cero utilizando un algoritmo de manejo de conexiones asíncrono, sin bloqueo y basado en eventos para aprovechar esta información.

NGINX genera procesos de trabajo, cada uno de los cuales es capaz de manejar decenas de miles de conexiones. Los procesos de trabajo logran esto mediante el desarrollo de un mecanismo de bucle rápido que verifica y procesa eventos de forma regular. Al desvincular el trabajo real de las conexiones, cada trabajador puede concentrarse en una conexión solo cuando se ha producido un nuevo evento.

Cada una de las conexiones del trabajador se coloca en el bucle de eventos, donde coexisten con otras conexiones. Los eventos se procesan de forma asíncrona dentro del ciclo, lo que permite que el trabajo se realice sin bloqueos. El enlace se elimina del ciclo después de que se cierra.

NGINX puede escalar excepcionalmente lejos con recursos mínimos gracias a su método de procesamiento de conexión. Debido a que el servidor es de subproceso único y no se generan procesos adicionales para manejar cada nueva conexión, el uso de la memoria y la CPU permanece relativamente constante, incluso cuando el servidor está bajo una presión intensa.

Contenido estático vs. dinámico

NGINX no tiene soporte nativo para el procesamiento de contenido dinámico. NGINX debe pasar PHP y otras solicitudes de contenido dinámico a un procesador externo para su procesamiento y luego esperar a que se devuelva el contenido procesado. El cliente puede entonces ser informado de los resultados.

Para los administradores, esto implica que la comunicación entre NGINX y el procesador debe configurarse utilizando uno de los protocolos que comprende NGINX (http, FastCGI, SCGI, uWSGI, memcache). Esto puede complicar un poco las cosas, especialmente al estimar la cantidad de conexiones a permitir, ya que cada llamada al procesador requerirá una nueva conexión.

Esta estrategia, por otro lado, proporciona algunos beneficios. La sobrecarga del intérprete dinámico solo estará presente para el material dinámico porque no está incluido en el proceso de trabajo. El contenido estático se puede enviar de manera sencilla, con el intérprete consultado solo cuando sea necesario. Esto también es posible con Apache, pero elimina los beneficios mencionados en la sección anterior.

Configuración distribuida frente a centralizada

NGINX no entiende los archivos .htaccess y no tiene una forma de evaluar la configuración por directorio fuera del archivo de configuración principal. Aunque es menos versátil que el enfoque de Apache, tiene su propio conjunto de beneficios.

El aumento del rendimiento es la ganancia más notable sobre el enfoque .htaccess de la configuración a nivel de directorio. Para cada solicitud, el servidor buscará estos archivos en cada uno de los directorios principales que conducen al archivo solicitado en una configuración estándar de Apache que permite .htaccess en cualquier directorio. Si esta búsqueda arroja uno o más archivos .htaccess , deben leerse y procesarse. NGINX puede atender solicitudes más rápido al ejecutar una sola consulta de directorio y lectura de archivo para cada solicitud al no permitir anulaciones de directorio (suponiendo que el archivo se encuentre en la estructura de directorio convencional).

Otro beneficio es que es seguro. La distribución del acceso a la configuración a nivel de directorio también distribuye las responsabilidades de seguridad a los usuarios individuales, en quienes se puede confiar o no para hacerlo correctamente. Al asegurarse de que el administrador tenga control total sobre el servidor web, puede evitar varios errores de seguridad que pueden surgir cuando se otorga acceso a otros.

Si le preocupan estos problemas, tenga en cuenta que puede deshabilitar la interpretación de .htaccess en Apache.

Interpretación basada en archivo VS URI

NGINX fue diseñado para funcionar como servidor web y como servidor proxy. Funciona principalmente con URI, traduciéndose al sistema de archivos cuando es necesario, debido a la arquitectura requerida para estos dos trabajos.

Esto se puede ver en la forma en que se construyen y procesan los archivos de configuración de NGINX en algunos casos.
NGINX no tiene una forma de especificar la configuración para un directorio de sistema de archivos, por lo tanto, analiza el URI.

Los bloques de servidor y ubicación, por ejemplo, son los bloques de configuración más importantes para NGINX. El bloque de servidor se encarga de interpretar el host solicitado, mientras que los bloques de ubicación se encargan de hacer coincidir partes del URI después del host y el puerto. La solicitud ahora se procesa como un URI en lugar de una ubicación del sistema de archivos.

Todas las solicitudes de archivos estáticos finalmente deben asignarse a un lugar en el disco. NGINX selecciona el servidor y los bloques de ubicación que procesarán la solicitud primero, luego combina la raíz del documento con el URI, modificando según sea necesario según la configuración.

Esto puede parecer similar, pero la interpretación de las solicitudes en gran medida como URI en lugar de ubicaciones del sistema de archivos facilita que NGINX sirva como servidor web, de correo y proxy. NGINX se configura definiendo cómo debe responder a ciertos patrones de solicitud. NGINX no inspecciona el sistema de archivos hasta que está listo para entregar la solicitud, por lo que no se admiten los archivos .htaccess .

Módulos

NGINX también tiene un sistema de módulos, sin embargo, es considerablemente diferente al de Apache. Los módulos en NGINX no se pueden cargar dinámicamente, por lo que deben elegirse y compilarse en el software principal.
NGINX se volverá mucho menos adaptable para muchos usuarios como resultado de esto. Esto es particularmente cierto para los usuarios que dudan en mantener su propio software construido fuera del esquema de empaquetado estándar de su distribución. Si bien la mayoría de los paquetes de distribuciones incluyen los módulos más utilizados, si necesita un módulo no estándar, deberá construir el servidor usted mismo desde la fuente.

Los módulos NGINX, por otro lado, siguen siendo bastante valiosos ya que le permiten especificar exactamente lo que desea de su servidor al incluir solo las funciones que desea usar. Algunos usuarios también pueden creer que ese enfoque es más seguro porque los componentes arbitrarios no se pueden conectar al servidor. Si su servidor alguna vez se encuentra en una situación en la que esto es concebible, es casi seguro que ya está comprometido.

Muchas de las mismas funciones están disponibles en los módulos NGINX que en los módulos Apache. El soporte de proxy, la compresión, la restricción de velocidad, el registro, la reescritura, la geolocalización, la autenticación, el cifrado, la transmisión y las funciones de correo están disponibles a través de los módulos NGINX.

Soporte, Compatibilidad, Ecosistema y documentación

NGINX está ganando popularidad a medida que más personas lo usan debido a su alto rendimiento, pero todavía tiene que ponerse al día en ciertas áreas cruciales.

Debido a que la mayor parte del desarrollo inicial y la documentación estaban en ruso, en el pasado era difícil localizar documentación sustancial en inglés para NGINX. La documentación se ha desarrollado a medida que ha crecido el interés en el proyecto, y actualmente hay muchos recursos de administración disponibles en el sitio de NGINX y a través de terceros.

El soporte y la documentación para aplicaciones de terceros están cada vez más disponibles, y los mantenedores de paquetes están comenzando a ofrecer opciones para la configuración automática de Apache y NGINX en algunas circunstancias. Configurar NGINX para operar con otro software suele ser sencillo incluso sin soporte, siempre que se documenten las necesidades del proyecto (permisos, encabezados, etc.).

Ventajas de NGINX

El servidor web NGINX es simple, liviano y rápido. Diseñado específicamente para sitios web con mucho tráfico.

• Utiliza una arquitectura sin bloqueo basada en eventos que usa menos CPU y memoria.
• Incluye muchas opciones de optimización y servicio para contenido estático. Como resultado, ofrece contenido estático 2,5 veces más rápido y usa menos memoria que Apache.
• Se desempeña admirablemente en un sistema multiprocesador.
• Los ataques DDoS se evitan mediante una opción de configuración integrada.

Desventajas de NGINX

• El contenido dinámico no se puede procesar de forma nativa.
• Hay disponible un número menor de módulos.
• Los sistemas operativos Linux y Unix son compatibles, sin embargo, la compatibilidad con Windows está restringida.
• El archivo .htaccess , que es compatible con Apache, no es compatible con NGINX.
• Escasez de software de monitoreo de registros: simplemente guarda los registros en archivos que se deben navegar manualmente.

Para usar Apache y NGINX juntos

Después de revisar las ventajas y desventajas de Apache y NGINX, debería poder determinar qué servidor se adapta mejor a sus necesidades. Muchos usuarios, sin embargo, encuentran que usar ambos servidores juntos les permite aprovechar los beneficios de cada servidor.

La configuración estándar para esta cooperación es usar NGINX como proxy inverso frente a Apache. Esto permitirá que NGINX procese todas las solicitudes de los clientes. Esto hace uso de la rápida velocidad de procesamiento y la capacidad de NGINX para administrar una gran cantidad de conexiones a la vez.

Los archivos se enviarán rápida y directamente al cliente para contenido estático, en lo que NGINX sobresale. NGINX transferirá las solicitudes de contenido dinámico, como secuencias de comandos PHP, a Apache, que procesará los resultados y proporcionará la página representada. Luego, el material se puede devolver al cliente a través de NGINX.

Para muchos usuarios, este diseño funciona bien ya que permite que NGINX actúe como una máquina clasificadora. Manejará cualquier solicitud que pueda y transmitirá aquellas que no sabe cómo manejar. Podemos reducir algunos de los bloqueos que ocurren cuando un proceso o subproceso de Apache está ocupado al reducir la cantidad de solicitudes que se le solicita al servidor Apache que maneje.

Puede escalar horizontalmente con este acuerdo agregando más servidores back-end según sea necesario. NGINX se puede configurar simplemente para reenviar solicitudes a un grupo de servidores, mejorando la tolerancia a fallas y el rendimiento de la configuración.

¿Cuándo usar Apache vs NGINX?

Tanto Apache como NGINX, como se describe en este artículo, son potentes, adaptables y buenos servidores web. Para sitios web de alto tráfico, Apache es mejor para proporcionar material dinámico, mientras que NGINX es mejor para proporcionar contenido estático o flujos de medios. Es tan simple como esto:

¿Cuándo puedes usar Apache?

• Si tiene un plan de alojamiento compartido.
• Si aprecia una comunidad útil con una multitud de recursos, este es el lugar para estar.
• Apache es popular entre los desarrolladores web porque es fácil de configurar.

¿Cuándo puedes usar NGINX?

• Si tienes un VPS o servidor dedicado.
• Eres el propietario de un sitio web popular con mucho contenido estático.
• Si desea administrar el tráfico entrante y distribuirlo a servidores ascendentes que son más lentos.

Apache vs. NGINX: ¿Cuál deberías elegir para tu servidor en 2022?

Cualquiera que sea el que proporcione su empresa de alojamiento es el que debe usar. En muchas circunstancias, no tendrá opción. Muchos proveedores web siguen la misma estrategia, que deberías seguir si te decides entre Apache y NGINX:

• Apache es una buena opción si desea hospedar un servidor que requiere una configuración constante o si desea brindarles a los usuarios una opción de configuración.
• NGINX, por otro lado, es el camino a seguir si desea un rendimiento ultrarrápido, una seguridad sólida como una roca y la capacidad de administrar configuraciones en lugar de sus usuarios.

Debido a su arquitectura fundamental, Apache puede ocupar más RAM en términos de rendimiento. En casos de alto tráfico, NGINX funcionará mejor, especialmente si hay mucho material estático para administrar.

Por lo tanto, NGINX puede ser la solución ideal si confía en el almacenamiento en caché para almacenar y servir contenido. Recuerde que NGINX no puede proporcionar material dinámico; por lo tanto, su rendimiento se verá afectado por la eficacia del proxy que utilice su servidor.

Conclusión

Como puede ver, tanto Apache como NGINX son poderosos, adaptables y capaces. Evaluar sus necesidades individuales y probar los patrones que espera ver son los criterios principales para seleccionar el servidor adecuado para usted.

Entre estos proyectos, existen diferencias significativas en el rendimiento bruto, las capacidades y el tiempo que lleva implementar cada uno. Sin embargo, a menudo son el resultado de una serie de compensaciones que no deben ignorarse. Por último, pero no menos importante, no existe un servidor web único para todos, así que elija la opción que se adapte a sus necesidades.