2010-11-05 39 views
10

Actualmente tengo un servidor con nginx que reverse_proxy a apache (el mismo servidor) para procesar solicitudes de php. Me pregunto si dejo caer apache para ejecutar nginx/fastcgi a php si veo algún tipo de aumento en el rendimiento. Asumo que lo haría desde que Apache está bastante hinchado, pero al mismo tiempo no estoy seguro de qué tan confiable sea fastcgi/php, especialmente en situaciones de mucho tránsito.nginx/apache/php vs nginx/php

Mis sitios reciben alrededor de 200,000 visitantes únicos al mes, con alrededor de 6,000,000 de páginas rastreadas de los motores de búsqueda mensualmente. Este número aumenta continuamente, así que estoy buscando opciones de rendimiento.

Mi sitio está muy optimizado para el código y no hay ningún almacenamiento en caché (tampoco quiero), cada página tiene un máximo de 2 consultas SQL sin combinaciones en otras tablas, los índices son perfectos también.

En un año más o menos estaré reescribiendo todo para usar ClearSilver para las plantillas, y luego probablemente use Python o C++ para un rendimiento extremo.

Supongo que estoy más o menos en busca de algún consejo de alguien que esté familiarizado con nginx/fastcgi y si está dispuesto a proporcionar algunos puntos de referencia. Mis sitios son un servidor con 1 quad core xeon, 8 gb ram, 150 gb velociraptor drive.

Respuesta

5

nginx definitivamente funcionará más rápido que Apache. No puedo hablar de fastcgi ya que nunca lo usé con nginx pero esta solución parece tener más sentido en varios servidores (uno para contenido estático y otro para fastcgi/PHP).

Si realmente está enfocando el rendimiento, e incluso considera C/C++, entonces debe probar G-WAN, un servidor todo en uno que proporciona scripts (muy rápidos).

No solo G-WAN tiene una huella de memoria ridículamente pequeña (120 KB) sino que se escala como ninguna otra cosa. Hay trabajo por delante si migra desde PHP, pero puede comenzar con las tareas críticas para el rendimiento y migrar progresivamente.

¡Hemos dado el salto y no podemos volver a Apache!

+0

G-WAN se ve muy muy bien! ¿Sabe usted aproximadamente cuántas conexiones podría manejar por segundo? – Joe

+1

He medido G-WAN a 200,000 solicitudes por segundo. Dado que el animal es un proceso de 32 bits, hay espacio para el progreso cuando se ejecutará en código de 64 bits (todos los demás servidores web son mucho más rápidos cuando se compilan en 64 bits que en 32 bits). – Frankie

+2

No siempre. Apache funciona mucho más rápido que nginx en máquinas multinúcleo grandes con una carga concurent muy dinámica (páginas dinámicas). Nginx es bueno para archivos estáticos o cuando lo usamos como proxy. – iddqd

2

Aquí es un diagrama que muestra las respectivas representaciones de nginx, Apache y g-wan:

g-wan.com/imgs/gwan-lighttpd-nginx-cherokee.png~~V~~3rd no parece

Apache liderar el paquete (y eso es un -Quad XEON @ 3GHz).

+0

Tenga en cuenta que esta tabla proviene directamente de g-wan, por lo que es más probable que favorezca g-wan. –

1

Aquí es un punto de referencia independiente para la g-Wan vs nginx, barnices y otros http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

g-wan maneja mucho más peticiones por segundo con mucho menos tiempo de CPU.

+0

¿Cómo sabes que es independiente? ;) ... Sólo curioso. – 0xC0000022L

+0

@STATUS_ACCESS_DENIED, los autores de g-wan y nginx comentaron en esa publicación de blog e incluso sugirieron algunos ajustes para el punto de referencia de sus servidores; lo que sugiere para mí que el punto de referencia no era defectuoso y se hizo de manera justa. replicar el punto de referencia como se detalla al comienzo de esa publicación y dejarnos saber lo que obtienes, independientemente;), g-wan ahora afirma una mejor administración de memoria que nginx que consumió la menor cantidad de memoria que el resto del servidor web en el benchmark. – Soroush

+0

Bastante justo. +1 – 0xC0000022L

Cuestiones relacionadas