Apache vs Nginx para PrestaShop: Qué servidor web ofrece mejor rendimiento

Por qué la elección del servidor web importa para PrestaShop

PrestaShop es una aplicación PHP que genera páginas HTML dinámicamente, sirve recursos estáticos como imágenes, archivos CSS y JavaScript, y gestiona peticiones AJAX tanto del front office como del back office. El servidor web se encuentra entre los visitantes y la aplicación PHP, manejando cada petición HTTP individual. Su arquitectura afecta directamente a cuántos visitantes simultáneos puede manejar la tienda, a la velocidad de carga de las páginas y a cuánta memoria del servidor consume cada visitante.

Apache y Nginx son los dos servidores web dominantes para alojar PrestaShop. Apache ha sido la opción predeterminada desde las primeras versiones de PrestaShop, y PrestaShop viene con archivos .htaccess diseñados específicamente para Apache. Nginx ha ganado una adopción masiva durante la última década gracias a su superior manejo de conexiones simultáneas y su menor huella de memoria. Ambos pueden ejecutar PrestaShop de forma efectiva, pero difieren en aspectos que importan para el rendimiento de la tienda, la complejidad de la configuración y la sobrecarga operativa.

Arquitectura: Modelo de procesos vs Bucle de eventos

La diferencia fundamental entre Apache y Nginx radica en cómo manejan las conexiones entrantes. Esta diferencia arquitectónica impulsa cada diferencia de rendimiento entre ambos servidores.

El modelo de procesos/hilos de Apache

Apache tradicionalmente utiliza un modelo basado en procesos a través de su módulo prefork MPM (Multi-Processing Module). En este modelo, Apache genera un pool de procesos trabajadores, y cada proceso maneja una petición a la vez. Cuando llega una petición, se le asigna un proceso. Ese proceso lee la petición, ejecuta el código PHP (si utiliza mod_php), envía la respuesta y solo entonces queda disponible para la siguiente petición.

El worker MPM utiliza hilos en lugar de procesos separados, permitiendo más conexiones simultáneas con menos memoria. El event MPM va más allá utilizando un enfoque basado en eventos para las conexiones keepalive mientras sigue usando hilos para el procesamiento activo de peticiones. Las instalaciones modernas de Apache típicamente usan el event MPM, pero el modelo fundamental sigue implicando dedicar un hilo a cada petición activa.

La implicación práctica es que la concurrencia de Apache está limitada por el número de hilos o procesos trabajadores configurados. Si configuras 150 workers y llegan 151 peticiones simultáneamente, la última espera en una cola. Cada worker consume memoria (típicamente 10-30 MB por proceso con mod_php, menos con PHP-FPM), por lo que el número máximo de workers está limitado por la RAM disponible.

El modelo orientado a eventos de Nginx

Nginx utiliza una arquitectura asíncrona orientada a eventos. Un pequeño número de procesos trabajadores (típicamente uno por núcleo de CPU) maneja miles de conexiones simultáneamente utilizando un bucle de eventos. Cuando llega una petición, Nginx la procesa de manera no bloqueante. Si Nginx necesita esperar por algo (una respuesta de PHP-FPM, una lectura de archivo del disco, una respuesta de un servidor backend), no bloquea el worker. En su lugar, pasa a manejar otras conexiones y regresa cuando la operación esperada se completa.

Esto significa que un proceso trabajador de Nginx manejando 1.000 conexiones simultáneas utiliza aproximadamente la misma memoria que cuando maneja 10 conexiones. La huella de memoria está determinada por el número de procesos trabajadores (un puñado), no por el número de conexiones (potencialmente miles). Por esto Nginx sobresale bajo alta concurrencia y es la opción preferida para sitios de alto tráfico.

.htaccess vs configuración del servidor

Una de las diferencias prácticas más significativas entre Apache y Nginx es cómo se manejan la reescritura de URLs, el control de acceso y otras configuraciones por directorio.

Apache y .htaccess

Apache soporta archivos .htaccess, que son archivos de configuración por directorio que pueden anular la configuración global del servidor. PrestaShop depende en gran medida de .htaccess para la reescritura de URLs amigables, el control de acceso, las cabeceras de caché y las cabeceras de seguridad. Cuando activas las URLs amigables en PrestaShop, genera un archivo .htaccess con reglas mod_rewrite que traducen URLs limpias como /shoes/running-shoe en la URL interna del dispatcher.

La ventaja de .htaccess es la comodidad. No necesitas acceso root para modificar el comportamiento del servidor web, y los cambios tienen efecto inmediato sin reiniciar el servidor. PrestaShop puede escribir su propio archivo .htaccess desde el back office, lo que significa que funcionalidades como URLs amigables, configuración del servidor de medios y ciertos ajustes de seguridad funcionan de forma inmediata.

La desventaja es el rendimiento. Cada petición hace que Apache busque y analice archivos .htaccess en cada directorio desde la raíz del documento hasta el directorio del archivo solicitado. En una petición típica de PrestaShop, Apache podría buscar .htaccess en /, /var, /var/www, /var/www/html y más. Esto añade E/S de disco y tiempo de procesamiento a cada petición. Para un sitio que maneja cientos de peticiones por segundo, esta sobrecarga es medible.

Si tienes acceso root a la configuración de Apache, puedes mover todas las directivas de .htaccess a la configuración del VirtualHost y desactivar el procesamiento de .htaccess con AllowOverride None. Esto elimina la sobrecarga por petición manteniendo la misma funcionalidad. Sin embargo, los cambios entonces requieren un reload de Apache para tener efecto.

Configuración de Nginx

Nginx no soporta archivos .htaccess. Toda la configuración reside en los archivos de configuración de los bloques server, típicamente bajo /etc/nginx/sites-available/ o /etc/nginx/conf.d/. Cada regla de reescritura de URL, directiva de control de acceso y cabecera de caché debe definirse en estos archivos.

Esto significa que cuando configuras PrestaShop en Nginx, debes traducir manualmente las reglas .htaccess de PrestaShop a la sintaxis de configuración de Nginx. Las reglas de reescritura son fundamentalmente diferentes entre ambos servidores. Apache usa RewriteRule con patrones regex y flags como [L,R=301], mientras que Nginx usa bloques location con directivas try_files, rewrite y return.

La ventaja de la configuración centralizada es el rendimiento (sin escaneo de archivos por petición) y la claridad (todas las reglas en un solo lugar). La desventaja es que PrestaShop no puede generar la configuración de Nginx por ti. Debes escribirla y mantenerla tú mismo, y cualquier cambio requiere ejecutar nginx -t para probar la sintaxis y systemctl reload nginx para aplicarlo.

Integración con PHP

Ambos servidores web necesitan ejecutar código PHP para generar las páginas de PrestaShop. El método de integración con PHP afecta al rendimiento, la estabilidad y la gestión de recursos.

Apache con mod_php

El enfoque tradicional es Apache con mod_php, donde PHP se ejecuta como un módulo dentro de cada proceso de Apache. Esto es sencillo de configurar y no tiene sobrecarga de comunicación entre procesos porque PHP se ejecuta en el mismo proceso que maneja la petición HTTP. Sin embargo, cada proceso trabajador de Apache lleva el runtime completo de PHP en memoria, incluso cuando sirve archivos estáticos como imágenes o CSS. Esto desperdicia memoria porque la mayoría de las peticiones a una tienda PrestaShop son para recursos estáticos, no páginas PHP.

Apache o Nginx con PHP-FPM

PHP-FPM (FastCGI Process Manager) ejecuta PHP como un pool de procesos separado. El servidor web se comunica con PHP-FPM a través de un socket Unix o una conexión TCP usando el protocolo FastCGI. Cuando una petición requiere procesamiento PHP, el servidor web la reenvía a PHP-FPM. Cuando el procesamiento PHP se completa, PHP-FPM devuelve el resultado al servidor web, que lo envía al cliente.

Con PHP-FPM, los procesos del servidor web que manejan archivos estáticos no llevan el runtime de PHP, ahorrando una cantidad significativa de memoria. PHP-FPM también ofrece su propia gestión de procesos con funcionalidades como el dimensionamiento dinámico del pool, el slow log (registro cuando una petición tarda más que un umbral) y la capacidad de ejecutar múltiples versiones de PHP simultáneamente para diferentes sitios.

Nginx utiliza exclusivamente PHP-FPM porque su arquitectura orientada a eventos es incompatible con incrustar PHP. Apache puede usar PHP-FPM a través de mod_proxy_fcgi. En implementaciones modernas, PHP-FPM es el enfoque recomendado para ambos servidores.

Configuración de PHP-FPM para PrestaShop

Independientemente del servidor web que elijas, la configuración de PHP-FPM afecta significativamente al rendimiento de PrestaShop. Los ajustes clave incluyen:

pm = dynamic es generalmente el mejor modo del administrador de procesos. Inicia un número base de workers y genera más bajo carga, hasta un máximo configurado. Esto equilibra el uso de memoria y la capacidad de respuesta.

pm.max_children determina el número máximo de procesos PHP. Cada petición de PrestaShop típicamente usa 30-80 MB de memoria, así que divide tu RAM disponible (menos lo que necesitan el servidor web y el sistema operativo) entre 80 para obtener un máximo conservador. Para un servidor con 4 GB de RAM utilizable, 50 procesos hijos es un punto de partida razonable.

pm.max_requests = 500 recicla cada worker después de 500 peticiones, previniendo que se acumulen fugas de memoria. Los módulos de PrestaShop ocasionalmente tienen pequeñas fugas de memoria, y este ajuste previene que se conviertan en un problema.

Servicio de archivos estáticos

Una tienda PrestaShop sirve grandes cantidades de archivos estáticos: imágenes de productos, hojas de estilo CSS, archivos JavaScript, fuentes y archivos multimedia subidos. El rendimiento del servicio de archivos estáticos afecta directamente a los tiempos de carga de las páginas y al uso de recursos del servidor.

Rendimiento de archivos estáticos en Apache

Apache sirve archivos estáticos a través de sus procesos trabajadores. Cada petición de archivo estático ocupa un worker durante la duración de la transferencia. Para archivos pequeños (CSS, JS, imágenes pequeñas), esto es rápido. Para archivos grandes o conexiones de cliente lentas, el worker está ocupado más tiempo. Con mod_php cargado, cada worker lleva una sobrecarga de memoria PHP innecesaria incluso para las peticiones estáticas.

Apache soporta sendfile, que permite al kernel transferir archivos directamente del disco al socket de red sin copiar datos a través del espacio de usuario. Esto está habilitado por defecto y ayuda con las transferencias de archivos grandes. Apache también soporta negociación de contenido, rangos de bytes y peticiones condicionales (If-Modified-Since) de forma nativa.

Rendimiento de archivos estáticos en Nginx

Nginx sobresale en el servicio de archivos estáticos porque su modelo orientado a eventos puede manejar miles de transferencias de archivos simultáneas sin aumentar proporcionalmente el uso de recursos. Un solo proceso trabajador de Nginx puede servir cientos de peticiones de archivos estáticos simultáneas. Combinado con el uso eficiente de la llamada al sistema sendfile y su soporte integrado para la caché de archivos abiertos (almacenamiento en caché de descriptores de archivo para archivos de acceso frecuente), el servicio de archivos estáticos es extraordinariamente rápido.

Para las tiendas PrestaShop con muchas imágenes de producto (que son la mayoría de las tiendas), la ventaja de rendimiento de Nginx en el servicio de archivos estáticos es significativa. Las páginas de producto con 5-10 imágenes, más archivos CSS, JavaScript y fuentes, generan 20-30 peticiones de archivos estáticos por carga de página. Bajo tráfico elevado, Nginx maneja estas peticiones con sustancialmente menos recursos que Apache.

Terminación SSL/TLS

Toda tienda PrestaShop debería funcionar sobre HTTPS, y el servidor web maneja la encriptación y desencriptación SSL/TLS (terminación). Ambos servidores soportan bien el TLS moderno, pero existen diferencias en configuración y rendimiento.

Apache configura SSL a través de mod_ssl, con directivas como SSLEngine on, SSLCertificateFile y SSLProtocol en el bloque VirtualHost. El grapado OCSP, el almacenamiento en caché de sesiones y la selección de suites de cifrado son todos configurables.

Nginx configura SSL en el bloque server con directivas como ssl_certificate, ssl_protocols y ssl_ciphers. Nginx también soporta grapado OCSP y almacenamiento en caché de sesiones, y su configuración tiende a ser más concisa.

En cuanto a rendimiento, el handshake TLS es intensivo en CPU debido a la encriptación asimétrica involucrada. La capacidad de Nginx para manejar muchas conexiones simultáneas con pocos procesos trabajadores significa que puede manejar más handshakes TLS por segundo con menos memoria. Para tiendas que reciben grandes oleadas de nuevos visitantes (durante una oferta, por ejemplo), la ventaja de rendimiento TLS de Nginx puede prevenir la puesta en cola de conexiones.

Reverse proxy y balanceo de carga

Para tiendas PrestaShop de alto tráfico, una arquitectura de reverse proxy separa responsabilidades y mejora la escalabilidad. La configuración más común utiliza Nginx como reverse proxy delante de Apache o de otra instancia de Nginx ejecutando PHP-FPM.

Nginx como reverse proxy para Apache

Esta configuración híbrida combina las fortalezas de ambos servidores. Nginx se sitúa al frente, manejando todas las conexiones entrantes, sirviendo archivos estáticos directamente, gestionando la terminación SSL y reenviando solo las peticiones PHP a Apache. Apache maneja el procesamiento PHP, y como solo recibe peticiones PHP (no peticiones de archivos estáticos), necesita muchos menos procesos trabajadores.

Esta arquitectura ofrece la eficiencia de manejo de conexiones de Nginx y el rendimiento en archivos estáticos, preservando al mismo tiempo el soporte de .htaccess de Apache para las reglas de reescritura generadas por PrestaShop. Es una ruta de migración común para tiendas que quieren el rendimiento de Nginx sin reescribir toda su configuración de Apache.

La configuración proxy de Nginx utiliza la directiva proxy_pass para reenviar peticiones a Apache, que típicamente se ejecuta en un puerto no estándar como 8080. Los archivos estáticos son servidos directamente por Nginx usando un bloque location que coincide con extensiones de archivo como .jpg, .css, .js y .png.

Configuración completa de Nginx

Para el máximo rendimiento, Nginx sirve todo: archivos estáticos y peticiones PHP (a través de PHP-FPM). No hay Apache en la pila. Esto elimina la comunicación entre procesos entre Nginx y Apache y elimina la sobrecarga de memoria de ejecutar dos servidores web. Sin embargo, requiere crear y mantener manualmente la configuración de Nginx para la reescritura de URLs de PrestaShop, lo que supone más trabajo inicial.

Configuración recomendada de Nginx para PrestaShop

Una configuración de Nginx en producción para PrestaShop necesita manejar URLs amigables, acceso al panel de administración, almacenamiento en caché de archivos estáticos, comunicación con PHP-FPM y seguridad. Los elementos clave incluyen un bloque server escuchando en los puertos 80 y 443, un bloque de configuración SSL con tus certificados, una directiva root apuntando a tu instalación de PrestaShop y varios bloques location.

El bloque location principal utiliza try_files $uri $uri/ /index.php?$args para manejar las URLs amigables de PrestaShop. Intenta servir la petición como archivo estático primero, luego como directorio, y finalmente la pasa al dispatcher de PrestaShop a través de index.php.

Un bloque location que coincide con ~ \.php$ reenvía las peticiones PHP a PHP-FPM usando fastcgi_pass. Incluye los parámetros FastCGI estándar y establece SCRIPT_FILENAME a la ruta correcta.

Un bloque location para recursos estáticos establece cabeceras de expiración de caché largas y desactiva el registro de acceso para reducir la E/S. Patrones de coincidencia como \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ capturan los tipos de archivo estático comunes.

Los bloques location relacionados con la seguridad deniegan el acceso a archivos y directorios sensibles: .htaccess, .git, config/ (excepto config/xml/ que PrestaShop necesita), vendor/, app/config/ y otros directorios que nunca deberían ser accesibles desde la web.

Configuración recomendada de Apache para PrestaShop

Apache con event MPM y PHP-FPM proporciona el mejor hosting de PrestaShop basado en Apache. La configuración del VirtualHost debería habilitar los módulos rewrite, headers, expires, deflate y proxy_fcgi.

El DocumentRoot apunta a tu instalación de PrestaShop. AllowOverride All habilita el procesamiento de .htaccess, que es necesario a menos que muevas todas las reglas de reescritura de PrestaShop a la configuración del VirtualHost.

La integración con PHP-FPM utiliza SetHandler o ProxyPassMatch para reenviar las peticiones .php al socket de PHP-FPM. El enfoque SetHandler con proxy:unix:/run/php/php-fpm.sock|fcgi://localhost es más sencillo y se recomienda para la mayoría de las configuraciones.

Habilita la compresión gzip con mod_deflate para tipos de contenido basados en texto: HTML, CSS, JavaScript, JSON, XML y SVG. Habilita el almacenamiento en caché del navegador con mod_expires, estableciendo tiempos de expiración largos para recursos estáticos y más cortos para HTML.

Benchmarks de rendimiento y diferencias en el mundo real

Los números crudos de los benchmarks varían enormemente según el hardware, la configuración, la versión de PHP y la versión de PrestaShop. En lugar de presentar números específicos que serían engañosos fuera de contexto, estos son los patrones que emergen consistentemente en los benchmarks de hosting de PrestaShop.

Para el servicio de archivos estáticos, Nginx es consistentemente 2-3 veces más rápido que Apache y usa significativamente menos memoria. Esta brecha se amplía a medida que aumenta la concurrencia. Con 100 conexiones simultáneas, la diferencia podría ser del 20%. Con 1.000 conexiones simultáneas, Nginx podría usar 10 veces menos memoria.

Para el procesamiento de peticiones PHP, el servidor web no es el cuello de botella. El tiempo de procesamiento de PHP-FPM domina el ciclo de vida de la petición, y ambos servidores web añaden una sobrecarga insignificante comparada con el tiempo que PHP pasa ejecutando código PrestaShop, consultando la base de datos y renderizando plantillas. La diferencia en el manejo de peticiones PHP entre Apache con PHP-FPM y Nginx con PHP-FPM es típicamente inferior al 5%, lo que está dentro del margen de error de medición para la mayoría de las tiendas.

Para cargas de trabajo mixtas (el escenario realista), la ventaja de Nginx proviene de su manejo eficiente de archivos estáticos junto con las peticiones PHP. La carga de una página genera una petición PHP y 20-30 peticiones de archivos estáticos. Nginx maneja las 20-30 peticiones estáticas con un consumo trivial de recursos, mientras que Apache asigna un hilo trabajador a cada una. Bajo tráfico elevado, esta diferencia en el consumo de recursos significa que Nginx puede sostener una concurrencia más alta antes de que el rendimiento se degrade.

La conclusión práctica es que para tiendas con menos de 50 visitantes simultáneos, la elección del servidor web no marca prácticamente ninguna diferencia perceptible. Para tiendas que se acercan o superan los 100 visitantes simultáneos, las ventajas arquitectónicas de Nginx se vuelven significativas.

Guía de migración: de Apache a Nginx

La migración de una tienda PrestaShop existente de Apache a Nginx implica traducir la configuración, probar exhaustivamente y realizar el cambio.

Paso 1: Traduce las reglas .htaccess

Abre tu archivo .htaccess de PrestaShop e identifica todas las reglas de reescritura activas. La sección crítica es la reescritura de URLs amigables, que típicamente comienza con RewriteCond %{REQUEST_FILENAME} !-f y RewriteRule .* - [E=REWRITEBASE:/]. Estas se traducen a la directiva try_files de Nginx mencionada en la sección de configuración anterior.

Las reescrituras del servidor de medios, el manejo de prefijos de idioma y cualquier redirección personalizada también necesitan traducción. Cada par de RewriteRule y RewriteCond de Apache debe convertirse a la directiva location, rewrite o return equivalente de Nginx.

Paso 2: Configura Nginx junto a Apache

Instala Nginx y configúralo para escuchar en un puerto diferente (como 8080) mientras Apache continúa ejecutándose en el puerto 80. Esto te permite probar la configuración de Nginx sin afectar al sitio en producción. Apunta Nginx a la misma raíz de documentos que Apache para que sirva los mismos archivos.

Paso 3: Prueba todo

Accede al sitio a través del puerto de Nginx y prueba todos los aspectos: la página principal, las páginas de categorías, las páginas de productos, el carrito, el proceso de pago, el panel de administración, las URLs amigables, la carga de imágenes y el enrutamiento de URLs multilingüe. Presta especial atención a los patrones de URL que involucran caracteres especiales o parámetros de consulta.

Paso 4: Realiza el cambio

Una vez completadas las pruebas, detén Apache y reconfigura Nginx para escuchar en los puertos 80 y 443. Recarga Nginx y verifica que el sitio en producción funcione correctamente. Mantén la configuración de Apache intacta durante unos días en caso de que necesites hacer un rollback.

Problemas comunes en la migración

El problema más común son las reglas de reescritura faltantes para el enrutamiento de URLs multilingüe de PrestaShop. Si tu tienda usa múltiples idiomas con códigos de idioma en la URL (como /en/, /de/, /fr/), asegúrate de que la configuración de Nginx maneje correctamente estos prefijos.

Otro problema común son los límites de tamaño de subida de archivos. Apache usa LimitRequestBody mientras que Nginx usa client_max_body_size. Si importas productos con imágenes grandes, establece client_max_body_size a al menos 20M.

Las peticiones AJAX del panel de administración que dependen de la reescritura de .htaccess pueden fallar si las reglas correspondientes de Nginx no están presentes. Prueba el panel de administración exhaustivamente, incluyendo la edición de productos, la gestión de pedidos y la configuración de módulos.

Cuál deberías elegir

Elige Apache si estás en un hosting compartido donde no controlas el servidor web, si dependes en gran medida de .htaccess para la configuración (reglas generadas por módulos, plugins de seguridad) o si no te sientes cómodo escribiendo y manteniendo archivos de configuración de Nginx. Apache con event MPM y PHP-FPM es una configuración sólida y bien soportada para tiendas PrestaShop con tráfico moderado.

Elige Nginx si tienes acceso root a tu servidor, tu tienda maneja un tráfico significativo (cientos o miles de visitantes simultáneos), quieres el menor uso de recursos posible para un nivel de tráfico dado o estás configurando un servidor nuevo y prefieres los beneficios a largo plazo de la arquitectura de Nginx. El esfuerzo inicial de configuración es un coste único que se amortiza en rendimiento y eficiencia de recursos.

Elige el enfoque de reverse proxy Nginx delante de Apache si quieres el rendimiento de Nginx para archivos estáticos y el manejo de conexiones pero necesitas el soporte de .htaccess de Apache para la compatibilidad con módulos PrestaShop que generan o dependen de reglas .htaccess.

Para la mayoría de las nuevas instalaciones de PrestaShop en un VPS o servidor dedicado, Nginx con PHP-FPM es la opción recomendada. La configuración está bien documentada, las ventajas de rendimiento son reales y la simplicidad operativa de una pila de servidor web único reduce la sobrecarga de mantenimiento. Para tiendas existentes en Apache que funcionan adecuadamente, la migración a Nginx es una optimización valiosa pero no una necesidad urgente, a menos que estés alcanzando los límites de rendimiento.