2010-03-27 16 views
7

Estoy planeando configurar nginx como proxy inverso. Tendré apache para entregar mi contenido dinámico, y nginx entregará el contenido estático.Cómo comparar la configuración de apache/nginx

Mi configuración que tengo ahora es simplemente Apache con fastCGI. Esto no me da problemas de configuración y funciona muy bien.

Después de haber configurado nginx quiero ejecutar algunos puntos de referencia para ver si realmente tengo algunos aumentos de rendimiento, de lo contrario volveré a cambiar.

¿Alguien sabe cómo puedo comparar este tipo de configuración? O tal vez alguien ya hizo esto y tiene algunos resultados enlatados, estaré encantado de escucharlos.

PS.Sé que esto es más un tipo serverfault de la pregunta, pero yo he visto numerosos mensajes sobre Apache y Nginx así que pensé que le daría una oportunidad

Respuesta

15

mejor solución? Siege.

herramienta de evaluación comparativa más precisa de lo ab

+1

bienvenido a SO. y lo verificare –

7

una palabra: ab

+0

Gracias por la respuesta simple. Nunca supe que apache tiene esa herramienta. ¿Esta herramienta solo me dará los resultados de referencia para apache? O esto también reflejará los cambios nginx que hice a la configuración. –

+1

solo hace consultas http, es una manera simple de comparar cualquier servidor http. – Javier

+2

ab -k -n 10000 -c 50 http: // url.a/prueba Esto puede probar las páginas frontales/estáticas o los passthroughs a apache para su contenido dinámico. Otra posibilidad es http://www.acme.com/software/http_load/, que le permite especificar una lista de URL para probar. ab es un punto de referencia de utilidad algo limitada pero, al menos, puede obtener algunas ideas generales a partir de él. –

6

Un par de cosas:

  1. No use ab. Es de un único subproceso y probablemente terminará comparando ab en lugar de su servidor HTTP.

  2. No ejecute la herramienta de estrés que utilice en el mismo sistema que el servidor. El servidor HTTP competirá con la herramienta para CPU y otros recursos. Además, la versión idealizada de una red de localhost no cuenta toda la imagen (ver el punto 4).

  3. Preste atención a la memoria y la utilización de la CPU durante las pruebas. Muchas personas nunca consideran este factor. Incluso si ambas configuraciones funcionan igual, si uno usa una fracción de la RAM/CPU, entonces usted tiene un ganador.

  4. RPS no es la única métrica significativa. Cosas como clientes lentos (teléfonos inteligentes 3G, redes congestionadas, computadoras lentas) pueden tener un impacto claramente negativo en los servidores con subprocesos. La configuración de laboratorio idealizada (localhost o switch aislado) no reflejará esto.

  5. Su script FCGI será el cuello de botella para cualquiera de los servidores. Sugeriría utilizar una herramienta que pueda extraer múltiples recursos (idealmente una página completa, incluido el contenido estático) para que pueda obtener una imagen completa de los tiempos de carga de la página.

Puede considerar el uso de una de las herramientas de prueba "basadas en la nube", como browsermob.com o loadimpact.com.

Cuestiones relacionadas