El servidor web NGINX de código abierto (y también balanceador, caché HTTP y servidor proxy reverso) ha demostrado su potencial y alternativa a Apache en solo 4 años con un 400% de crecimiento.
#7:
Un 10? El titular de la noticia original (NGINX turns 10) se refiere a que NGINX cumple 10 años!
#6:
#1#2 ¿mala configuración de apache? ¿se están creando los mismos procesos? ¿se están ejecutando en las mismas condiciones, has deshabilitado todos los plugins que no se usan, has optimizado las opciones de arranque y funcionamiento? ¿o simplemente "con las opciones por defecto en ambos casos"?
Es cierto que nginx es más ligero, rápido y eficiente, por eso habría que compararlo con lighttp más que con apache. Es como comparar un oracle con un mysql, habría que ver exactamente qué carga y qué tipo de datos se mueven en cada uno, porque para pequeñas cargas está claro que mysql le pega un buen repasito, ahora, en cuanto la cosa crece bastante...
#1:
Justo ayer estaba haciendo pruebas para migrar unos sitios con wordpress de apache a nginx + fgci y quedé fascinado por lo eficiente que es. No sólo se nota más ligero sino que la primera prueba que he hecho consume un cuarto menos de memoria RAM. Yo ya no vuelvo a apache si puedo evitarlo.
#2:
#1 No solo eso en RAM y CPU, sino también en cuanto mucha gente hace muchas peticiones por segundo, tengo una web que antes con apache2 su tiempo de carga eran 4s por la cantidad de peticiones que recibia, pero lo cambie a nginx y paso a 98ms, y como tu has dicho, fascinante.
#21:
#14 Ni nginx ni apache pueden 'ejecutar' php. Ambos usan la misma aproximación, usar php-cgi (o php-fpm, o...), un 'listener' que escucha peticiones de ejecución de php y las sirve.
Por lo demás, nginx sí es proxy/balanceador, pero meter un nginx delante de un apache se suele usar para cosas muy específicas (como servir SVN, por ejemplo) en las que el desarollo de nginx aún flaquea. Pero son bien pocas, créeme.
Justo ayer estaba haciendo pruebas para migrar unos sitios con wordpress de apache a nginx + fgci y quedé fascinado por lo eficiente que es. No sólo se nota más ligero sino que la primera prueba que he hecho consume un cuarto menos de memoria RAM. Yo ya no vuelvo a apache si puedo evitarlo.
#1 No solo eso en RAM y CPU, sino también en cuanto mucha gente hace muchas peticiones por segundo, tengo una web que antes con apache2 su tiempo de carga eran 4s por la cantidad de peticiones que recibia, pero lo cambie a nginx y paso a 98ms, y como tu has dicho, fascinante.
#1#2 ¿mala configuración de apache? ¿se están creando los mismos procesos? ¿se están ejecutando en las mismas condiciones, has deshabilitado todos los plugins que no se usan, has optimizado las opciones de arranque y funcionamiento? ¿o simplemente "con las opciones por defecto en ambos casos"?
Es cierto que nginx es más ligero, rápido y eficiente, por eso habría que compararlo con lighttp más que con apache. Es como comparar un oracle con un mysql, habría que ver exactamente qué carga y qué tipo de datos se mueven en cada uno, porque para pequeñas cargas está claro que mysql le pega un buen repasito, ahora, en cuanto la cosa crece bastante...
#6 En la configuración de mi apache2, tenia algunos plugins como el ssl, y los que venían por defecto (creo que desactive algunos), y luego tenia muchos procesos por la cantidad de peticiones (1000 usuarios mínimo en hora punta). No llegue a mirar de hacer configuraciones porque fue cuando me recomendaron nginx y en 24h hice el traspaso de todo.
Y luego, la pagina generaba peticiones bestias, de actualizarse cada 15s porque era una herramienta para un juego. (Ahora a 10s y tira perfectamente)
#11 Le puse Cloudflare para ver si hacia algo, y bueno hacia algo, reducia la cantidad de trafico pero que digamos, que no ayudaba del todo, solo en algo. Y sigo manteniendo cloudflare en la web esta que estoy mencionando.
Apache tiene un caché http casi siempre activada por defecto (que igual tenía unos valores de configuración conservadores o demasiado pequeños para tu sitio), nginx cachea contenidos al estilo squid, de manera más exhaustiva. Quizá tenga algo que ver también.
#23 bueno, ya me pondré a mirarlo cuando pueda, tengo un vps donde hago pruebas antes de hacerlas en mi dedicado, así que ahí puedo mirar de trastear con el squid-cache, hace tiempo que no lo toco.
#28 Básicamente si, así se como funciona algo, y puedo usarlo en un futuro cuando lo necesite de verdad, o alguien de mi entorno necesite utilizar eso si no quiere cambiar lo que esta usando.
#4 Yo uso wp y drupal en el mismo VPS con nginx. Cacheo de wp/D7 (hablo del que incorporan) desactivado. Eso sí, el php sí que está optimizado y hay un microcaché para el html. Los tiempos son los que ves en el enlace que han puesto por ahí.
#13 Pero supongo que el microcaché html también lo tenías en apache, vamos que la migración ha sido con las mismas variables a nginx ¿no?
Habrá que probarlo entonces
#14 Sí, yo había visto que lo más eficiente era usar nginx de front con apache por detrás, tanto de balanceador como de proxy inverso.
#9 Apache en las raspberry no es una opción muy viable Yo uso lighttpd, que para algunas paginas simples que tengas y que solo uses tu va genial. No se si nginx aporta alguna ventaja de rendimiento respecto a lighttpd.
#36 Como te han dicho, no es difícil. Sólo diferente. Y si usas gnunicorn, entiendo que lo quieres usar como proxy/balanceo. Eso lo montas en cero coma. Ya verás.
#40 Exacto, la idea es usarlo como proxy, es la configuración que te aconsejan para poner en producción un sitio web hecho con django, es que hasta ahora sólo he jugado con el servidor de pruebas que trae django, por lo que veo hay bastante documentación por doquier, a ver qué tal se me da. Gracias!
#39 para eso tienes que hacer varios pools en php-fpm, con sockets distintos y luego en cada server de nginx apuntas cada web a cada usuario y listo, algo así http://pastebin.com/pMwXkNaC
#41#40 para django yo estoy usango nxing+gunicorn (arrancado desde supervisord) y va como un tiro ^^ al fina solo tienes que decirle que haga un proxy_pass a la IP/puerto donde esté gunicorn levantado y listo.
Es posible que las estadísticas de Nginx esté falseadas. Como bien dice la entradilla, Nginx es proxy inverso y también hace la función de balancear la carga lo que significa que, aunque nginx de la cara ante el público a la hora de gestionar el tráfico, hay unas cuantas implementaciones donde Apache trabaja detrás de nginx y es Apache el que hace en realidad el trabajo duro.
Eso hace que la cabecera HTTP indique que el servidor es nginx cuando la realidad es que es Apache quien está detrás de casi todo el trabajo. Por ejemplo hasta donde sé, nginx no puede ejecutar PHP, por lo que necesita Apache para realizar estas tareas.
#14 Algo erróneo en que necesita apache, mi dedicado tiene totalmente desinstalado el apache y solo tiene el nginx, y con este paquete: php5-fpm, te permite usar el fastcgi de nginx para las peticiones de .php
#14 Ni nginx ni apache pueden 'ejecutar' php. Ambos usan la misma aproximación, usar php-cgi (o php-fpm, o...), un 'listener' que escucha peticiones de ejecución de php y las sirve.
Por lo demás, nginx sí es proxy/balanceador, pero meter un nginx delante de un apache se suele usar para cosas muy específicas (como servir SVN, por ejemplo) en las que el desarollo de nginx aún flaquea. Pero son bien pocas, créeme.
#21 Apache también tiene mod_php, que es más eficiente que php-fpm y muy mucho más que php-cgi (que no es "listener", es ejecutar un proceso nuevo a pelo).
#53 Discrepo. El sistema php-fpm tiene la ventaja de que está constantemente ejecutándose, por tanto, la respuesta del sistema a una solicitud de ejecución es más rápida. También puedes definir la cantidad de memoria asignada a los pools de php-fpm. Igual es que me gusta más este tipo de "arquitectura modular" que no un mamotreto monolítico que lo hace todo. Le veo más ventajas.
#55 ¿Y acaso Apache no? Por defecto el mpm_prefork también "está constantemente ejecutándose", pero además de eso tienes mpm_worker, que aprovecha no solo procesos sino también hilos, o mpm_peruser que permite aislar cada grupo de procesos según su propietario. Al estar mod_php integrado, ambos efectos se trasladan a él. Con mpm_peruser también puedes tirar de límites por cgroups para limitar memoria, cpu, o lo que haga falta... aunque también podrías usarlos con php-fpm, supongo. De todas formas, creo recordar que la diferencia en rendimiento tampoco era tan grande, en torno al 10% o algo así.
#52 PD: la config a la que me refiero es "nginx + php-fpm" vs. "nginx + apache mod_php". Pero como siempre, todo dependerá de la aplicación y el entorno.
No es mérito de Nginx, es demérito de los que administradores que no configuran y aprietan las tuercas a sus Apache. Nginx ya viene tuneado, Apache no.
Por cierto, todos los servidores P0rn de entidad en internet corren sobre Nginx
#5 Como administrador, te diré que lo mejor es que en lugar de un hosting, te plantees un VPS baratillo. Las posibilidades de ajustar nginx son tantas y a tantos niveles que un nginx "cocinado" no tiene nada que hacer contra uno configurado para tus necesidades.
Además, la estructura, la organización interna, la documentación... Todo es tan grande, y a la vez tan progresivo que es sencillo de dominar y pasar de un servidor web "eficiente" a uno "estratosférico" a poco que estés un poco pendiente de él y vayas ajustando en función del site.
#10 Una preguntilla, ¿es muy complicado meterse de primeras con nginx? tengo cero experiencia en montar servidores web y próximamente voy a empezar a montar un servidor nginx con gnunicorn para una web app en django y la verdad es que no sé ni por dónde empezar.
Pues yo las veces que he tenido que tocar algo de nginx me he vuelto loco, instalar un simple phpmyadmin, no lo conseguí, en apache es algo trivial. Se que se puede, pero me pareció mucho más confuso, aunque claro, no estaba acostumbrado a él, la verdad.
Algún día me pondré a mirarlo más a fondo... en cuanto tenga un rato
Yo he puesto este año un proxy con nginx delante de más de 1000 webs (en un ISP de aquí) aunque luego el servidor final es un apache (por temas de compatibilidad, htaccess y demás) y ya es el servidor web por defecto que monto si el cliente no tiene rewrites raros la verdad que es una maravilla.
Ahora estoy a ver si me empapo de LUA para sacarle aún más ventajas.
Yo ya estoy a un paso de mudar mis webs del servidor a Nginx pero aún voy verde en un tema del PHP-FPM que es separar los procesos del PHP-FPM por usuarios del sistema. Así lo tengo en Apache2 con apache-worker-itk y no he visto un tutorial decente para hacer ese proceso en el FPM+Nginx. Parece chorrada pero cada web separada por un usuario del sistema y no todas las webs en uno solo aumenta mucho la seguridad.
Por el momento lo que voy a hacer es pasar Apache en otro puerto y usar de front Nginx como proxy inverso+cache y bloquear el acceso de Apache por IPtables.
Comentarios
Un 10? El titular de la noticia original (NGINX turns 10) se refiere a que NGINX cumple 10 años!
#7 También es mas correcto en nuestro idioma llamarlo "Proxy inverso" y no "Proxy reverso".
#7 nivel inglés medio, if if, between between
Justo ayer estaba haciendo pruebas para migrar unos sitios con wordpress de apache a nginx + fgci y quedé fascinado por lo eficiente que es. No sólo se nota más ligero sino que la primera prueba que he hecho consume un cuarto menos de memoria RAM. Yo ya no vuelvo a apache si puedo evitarlo.
#1 No solo eso en RAM y CPU, sino también en cuanto mucha gente hace muchas peticiones por segundo, tengo una web que antes con apache2 su tiempo de carga eran 4s por la cantidad de peticiones que recibia, pero lo cambie a nginx y paso a 98ms, y como tu has dicho, fascinante.
#2 ¿Hacemos una prueba? Apretando tuercas al nginx
Apretando tuercas al nginx
bofhers.net#1 #2 ¿mala configuración de apache? ¿se están creando los mismos procesos? ¿se están ejecutando en las mismas condiciones, has deshabilitado todos los plugins que no se usan, has optimizado las opciones de arranque y funcionamiento? ¿o simplemente "con las opciones por defecto en ambos casos"?
Es cierto que nginx es más ligero, rápido y eficiente, por eso habría que compararlo con lighttp más que con apache. Es como comparar un oracle con un mysql, habría que ver exactamente qué carga y qué tipo de datos se mueven en cada uno, porque para pequeñas cargas está claro que mysql le pega un buen repasito, ahora, en cuanto la cosa crece bastante...
#6 En la configuración de mi apache2, tenia algunos plugins como el ssl, y los que venían por defecto (creo que desactive algunos), y luego tenia muchos procesos por la cantidad de peticiones (1000 usuarios mínimo en hora punta). No llegue a mirar de hacer configuraciones porque fue cuando me recomendaron nginx y en 24h hice el traspaso de todo.
Y luego, la pagina generaba peticiones bestias, de actualizarse cada 15s porque era una herramienta para un juego. (Ahora a 10s y tira perfectamente)
#8 ¿y tenías algún tipo de caché instalado?
#11 Le puse Cloudflare para ver si hacia algo, y bueno hacia algo, reducia la cantidad de trafico pero que digamos, que no ayudaba del todo, solo en algo. Y sigo manteniendo cloudflare en la web esta que estoy mencionando.
#12 Me refería más a algo así como: http://www.squid-cache.org/
Apache tiene un caché http casi siempre activada por defecto (que igual tenía unos valores de configuración conservadores o demasiado pequeños para tu sitio), nginx cachea contenidos al estilo squid, de manera más exhaustiva. Quizá tenga algo que ver también.
#23 bueno, ya me pondré a mirarlo cuando pueda, tengo un vps donde hago pruebas antes de hacerlas en mi dedicado, así que ahí puedo mirar de trastear con el squid-cache, hace tiempo que no lo toco.
#27 Si ya nginx hace las mismas funciones que squid (y además sirve http) casi que mejor lo haces por didáctica para si te hace falta más adelante ;).
#28 Básicamente si, así se como funciona algo, y puedo usarlo en un futuro cuando lo necesite de verdad, o alguien de mi entorno necesite utilizar eso si no quiere cambiar lo que esta usando.
#28 #27 #23 El caché de nginx tiene más de varnish que de squid
#31 Nunca había oído hablar de eso, hoy creo que dejare frito el vps de tantas pruebas , gracias por el apunte.
#8 dejar de usar .htaccess es mano de santo
#20 Lo se, he aprendido una lección, y sinceramente, prefiero tener las configuraciones en cfg, que en ese archivo.
#22 Deflate activado, expires, AllowOverride none para que no compruebe .htaccess, +FollowSymLinks -SymLinksIfOwnerMatch para evitar I/O ..
#1 ¿con wordpress cacheado o en dinámico?
#4 Yo uso wp y drupal en el mismo VPS con nginx. Cacheo de wp/D7 (hablo del que incorporan) desactivado. Eso sí, el php sí que está optimizado y hay un microcaché para el html. Los tiempos son los que ves en el enlace que han puesto por ahí.
#13 Pero supongo que el microcaché html también lo tenías en apache, vamos que la migración ha sido con las mismas variables a nginx ¿no?
Habrá que probarlo entonces
#14 Sí, yo había visto que lo más eficiente era usar nginx de front con apache por detrás, tanto de balanceador como de proxy inverso.
#17 No. Es una instalación de nginx a pelo. Nunca hubo un apache.
Yo uso ngnix en burbuja.info (foro de vbulletin) y he notado una barbaridad la mejora de rendimiento.
#46 buena web
No lo conocía, gracias. Lo primero que he hecho es ver si hay algún manual para dejarlo en la raspberry y... para quien le interese: http://www.raspipress.com/2014/06/tutorial-install-nginx-and-php-on-raspbian/ Tiene que ser interesante para servidor casero lowcost.
#9 Apache en la raspby es muy muy pesado.
Aquí mi experiencia con nginx + raspberry:
http://it-cave.com/experiencia-montando-una-web-sobre-una-raspberry-pi/
#5 #10 yo estoy encantadísimo con Digital Ocean, el servidor de 5$ al mes me aguantó dos efectos menéame sin pestañear: https://www.digitalocean.com/?refcode=fe2cac13bf3f (lleva un código de referido).
#9 Apache en las raspberry no es una opción muy viable Yo uso lighttpd, que para algunas paginas simples que tengas y que solo uses tu va genial. No se si nginx aporta alguna ventaja de rendimiento respecto a lighttpd.
#9 Otra alternativa low cost es pillarse un droplet en Digital Ocean (son 5 dolares al mes).
Yo tengo mi blog, mi pagina personal y otra aplicacion, corriendo en un droplet asi, con nginx configurando los subdominios y va bastante bien.
Es que nadie recuerda el servidor web español, Cherokee http://cherokee-project.com/ .
Que viejo me siento .
#43 Claro que si pero no triunfo una pena.
#47 A mi me molaba, era todo mas fácil de hacer. Creo que el problema fue que su subieron al carro de Solaris pero vino oracle y jodio todo.
#36 Como te han dicho, no es difícil. Sólo diferente. Y si usas gnunicorn, entiendo que lo quieres usar como proxy/balanceo. Eso lo montas en cero coma. Ya verás.
#40 Exacto, la idea es usarlo como proxy, es la configuración que te aconsejan para poner en producción un sitio web hecho con django, es que hasta ahora sólo he jugado con el servidor de pruebas que trae django, por lo que veo hay bastante documentación por doquier, a ver qué tal se me da. Gracias!
#39 para eso tienes que hacer varios pools en php-fpm, con sockets distintos y luego en cada server de nginx apuntas cada web a cada usuario y listo, algo así http://pastebin.com/pMwXkNaC
#41 #40 para django yo estoy usango nxing+gunicorn (arrancado desde supervisord) y va como un tiro ^^ al fina solo tienes que decirle que haga un proxy_pass a la IP/puerto donde esté gunicorn levantado y listo.
#42 Fantastico el pastebin. Muchas gracias!
Yo recientemente he estado probando nginx como balanceador de carga y proxy inverso y por ahora va todo perfecto. Muy versátil, estable y rápido.
Es posible que las estadísticas de Nginx esté falseadas. Como bien dice la entradilla, Nginx es proxy inverso y también hace la función de balancear la carga lo que significa que, aunque nginx de la cara ante el público a la hora de gestionar el tráfico, hay unas cuantas implementaciones donde Apache trabaja detrás de nginx y es Apache el que hace en realidad el trabajo duro.
Eso hace que la cabecera HTTP indique que el servidor es nginx cuando la realidad es que es Apache quien está detrás de casi todo el trabajo. Por ejemplo hasta donde sé, nginx no puede ejecutar PHP, por lo que necesita Apache para realizar estas tareas.
#14 Algo erróneo en que necesita apache, mi dedicado tiene totalmente desinstalado el apache y solo tiene el nginx, y con este paquete: php5-fpm, te permite usar el fastcgi de nginx para las peticiones de .php
#14 http://www.laheliadoparda.com está con nginx, y está hecha con PHP.
#14 Ni nginx ni apache pueden 'ejecutar' php. Ambos usan la misma aproximación, usar php-cgi (o php-fpm, o...), un 'listener' que escucha peticiones de ejecución de php y las sirve.
Por lo demás, nginx sí es proxy/balanceador, pero meter un nginx delante de un apache se suele usar para cosas muy específicas (como servir SVN, por ejemplo) en las que el desarollo de nginx aún flaquea. Pero son bien pocas, créeme.
#21 Apache también tiene mod_php, que es más eficiente que php-fpm y muy mucho más que php-cgi (que no es "listener", es ejecutar un proceso nuevo a pelo).
#51 ...con lo que el footprint en memoria de apache se dispara. Por si no pesase bastante...
#52 Se dispara menos que con php-fpm, que es básicamente mod_php sin Apache. Así que estamos en las mismas.
#53 Discrepo. El sistema php-fpm tiene la ventaja de que está constantemente ejecutándose, por tanto, la respuesta del sistema a una solicitud de ejecución es más rápida. También puedes definir la cantidad de memoria asignada a los pools de php-fpm. Igual es que me gusta más este tipo de "arquitectura modular" que no un mamotreto monolítico que lo hace todo. Le veo más ventajas.
#55 ¿Y acaso Apache no? Por defecto el mpm_prefork también "está constantemente ejecutándose", pero además de eso tienes mpm_worker, que aprovecha no solo procesos sino también hilos, o mpm_peruser que permite aislar cada grupo de procesos según su propietario. Al estar mod_php integrado, ambos efectos se trasladan a él. Con mpm_peruser también puedes tirar de límites por cgroups para limitar memoria, cpu, o lo que haga falta... aunque también podrías usarlos con php-fpm, supongo. De todas formas, creo recordar que la diferencia en rendimiento tampoco era tan grande, en torno al 10% o algo así.
Aunque... también está mpm_event, del que no he probado el rendimiento, pero posiblemente esté mucho más cerca del de NGINX: https://httpd.apache.org/docs/2.4/mod/event.html
#52 PD: la config a la que me refiero es "nginx + php-fpm" vs. "nginx + apache mod_php". Pero como siempre, todo dependerá de la aplicación y el entorno.
No es mérito de Nginx, es demérito de los que administradores que no configuran y aprietan las tuercas a sus Apache. Nginx ya viene tuneado, Apache no.
Por cierto, todos los servidores P0rn de entidad en internet corren sobre Nginx
¿Hay empresas de hosting que usen nginx? Tiene buena pinta
edito: he visto algunas americanas y de momento los precios son algo altos, seguiré investigando
#5 Como administrador, te diré que lo mejor es que en lugar de un hosting, te plantees un VPS baratillo. Las posibilidades de ajustar nginx son tantas y a tantos niveles que un nginx "cocinado" no tiene nada que hacer contra uno configurado para tus necesidades.
Además, la estructura, la organización interna, la documentación... Todo es tan grande, y a la vez tan progresivo que es sencillo de dominar y pasar de un servidor web "eficiente" a uno "estratosférico" a poco que estés un poco pendiente de él y vayas ajustando en función del site.
#10 Una preguntilla, ¿es muy complicado meterse de primeras con nginx? tengo cero experiencia en montar servidores web y próximamente voy a empezar a montar un servidor nginx con gnunicorn para una web app en django y la verdad es que no sé ni por dónde empezar.
#36 Empieza por leerte la documentación (http://nginx.org/en/docs/). No es difícil, sólo diferente a como se configura Apache.
#5 la última versión de parallels ya viene con la opción de servir los archivos con NGINX
#45 #5 Cierto el panel plesk lleva ningx como proxy de apache.
#5 También muchas empresas de hosting españolas pone nginx, nosotros lo hacemos en Stackscale
Pues yo las veces que he tenido que tocar algo de nginx me he vuelto loco, instalar un simple phpmyadmin, no lo conseguí, en apache es algo trivial. Se que se puede, pero me pareció mucho más confuso, aunque claro, no estaba acostumbrado a él, la verdad.
Algún día me pondré a mirarlo más a fondo... en cuanto tenga un rato
#19 En cuestión de facilidad de configuración, y rendimiento sin muchos líos, a mi forma de ver los mejores son lighttp y cherokee
Yo he puesto este año un proxy con nginx delante de más de 1000 webs (en un ISP de aquí) aunque luego el servidor final es un apache (por temas de compatibilidad, htaccess y demás) y ya es el servidor web por defecto que monto si el cliente no tiene rewrites raros la verdad que es una maravilla.
Ahora estoy a ver si me empapo de LUA para sacarle aún más ventajas.
Yo ya estoy a un paso de mudar mis webs del servidor a Nginx pero aún voy verde en un tema del PHP-FPM que es separar los procesos del PHP-FPM por usuarios del sistema. Así lo tengo en Apache2 con apache-worker-itk y no he visto un tutorial decente para hacer ese proceso en el FPM+Nginx. Parece chorrada pero cada web separada por un usuario del sistema y no todas las webs en uno solo aumenta mucho la seguridad.
Por el momento lo que voy a hacer es pasar Apache en otro puerto y usar de front Nginx como proxy inverso+cache y bloquear el acceso de Apache por IPtables.