2012-09-16 26 views
5

Lighttpd, nginx y otros utilizan una variedad de técnicas para proporcionar el máximo rendimiento de la aplicación, como AIO, sendfile, MMIO, caché y epoll y bloquear las estructuras de datos libres.Técnicas para mejorar la tasa de transacción

Mi colega y yo hemos escrito un pequeño servidor de aplicaciones que utiliza muchas de estas técnicas y también puede server archivos estáticos. Así que lo probamos con apache bench y comparamos el nuestro con lighttpd y nginx y al menos hemos igualado el rendimiento del contenido estático para archivos de 100 bytes a 1K.

Sin embargo, cuando comparamos la tasa de transacción sobre los mismos archivos estáticos con la de G-WAN, G-WAN está muy adelante.

Sé que esta pregunta puede ser un poco subjetiva, pero ¿qué técnicas, aparte de las obvias que he mencionado, podrían usar Pierre Gauthier en GWAN que le permitirían lograr un rendimiento tan asombroso?

Respuesta

4

Siguiendo al servidor G-WAN durante años, he leído las (muchas) charlas que cubren esta pregunta en el viejo foro G-WAN.

Por lo que puedo recordar, lo que se dirigió en varias ocasiones fuera del programa:

  1. arquitectura (comparaciones específicas se hicieron con Nginx, lighty y Cherokee)
  2. aplicación (la forma general de ramificación, solicitar el análisis y la respuesta edificio se hicieron)
  3. camino común magra (la trayectoria seguida por todos los tipos de solicitudes: dinámicas y estáticas, manipuladores)

Pierre menudo mentionn ed otros servidores para explicar lo que en su arquitectura específica y su implementación los estaba ralentizando.

Como pasa el tiempo, dado que G-WAN parece apilar más y más características (soporte de scripts C#, se espera un proxy inverso y un equilibrador de carga con la próxima versión), parece que esos 3 puntos son más y más importante.

Esta es probablemente la razón por la que cada nuevo lanzamiento de G-WAN parece estar dispuesto a ser más rápido que el anterior: mientras más trabajo hagas, más grasa extra se debe eliminar porque su costo aumenta. Y como para un auto de carreras o un avión, este es un proceso gradual, uno que requiere más del otro.

Si está buscando el "secreto" de la velocidad de G-WAN, entonces creo que este es el punto clave. Pero si desea obtener más información, debería hablar directamente con el autor de G-WAN.

+0

El diseño es el más obvio. Sin embargo, las pruebas posteriores muestran que la carga de mi CPU es de alrededor del 30%. El cuello de botella parece ser la tarjeta de red o kernel. GWAN todavía está superando lo que tenemos.¿Hay algún truco especial de inicialización involucrado en la actualización de los paquetes a través de la tarjeta de red? – Matt

+0

Si el cuello de botella era el kernel, G-WAN no podría ser más rápido que otros. La carga de la CPU de G-WAN es menor porque su código * de modo de usuario es (mucho) más rápido. El servlet ** hello.c ** no toca el disco, por lo que el kernel no está involucrado para cargar un archivo, y aquí también G-WAN es más rápido que un módulo nginx (que, a diferencia de los servlets G-WAN, NO se carga dinámicamente) entonces debería tener una ventaja). Código más rápido, más simple y mejor arquitectura de programa. De eso se trata G-WAN. – Gil

1

Consulte la línea de tiempo de G-WAN. Una actualización el 8 de agosto de 2011 puede darle una idea de lo que está usando.

G-WAN Timeline

Pierre mencionado que el G-WAN utiliza es esperar libre tienda de valor-clave en gran medida de las funciones básicas de G-WAN. Lo que le da más velocidad ya que no se usan bloqueos.

También utiliza una técnica inspirada de Lorenz Waterwheel para manejar los hilos. No estoy seguro de cómo funciona, pero dijo que permite que G-WAN corra más rápido en todos los casos posibles.

+0

A la derecha, la tienda KV se usa para listas como los servidores virtuales y los servlets en varios idiomas, mientras que Lorenz Waterwheel es la forma en que se organiza la arquitectura para tratar con los subprocesos de trabajo. El punto es que Waterwheel * se ajusta * dinámicamente con la carga para ofrecer la mejor respuesta posible a pesar de las condiciones de carga cambiantes. – Gil

+0

Excepto que la publicación de páginas estáticas no necesita tocar el almacén de claves/valores. A menos que lo esté usando como un caché Además, dudo que sea más rápido que mdb. En realidad, si buscas lo que es un Lorenz Waterwheel, esencialmente significa aleatorio. Creo que está inventando alguna jerga que suena bien pero que no es lo que realmente está haciendo. – Matt

+0

¿Puedes demostrar que mdb es más rápido que la tienda G-WAN KV? Lorenz Waterwheel no es solo aleatorio. Otro concepto es la sensibilidad a la condición inicial. Esto se puede aplicar a los núcleos como condición inicial. El algoritmo funcionará de manera completamente diferente cuando se utilizan 1,2,4 ... núcleos. Mi conjetura es que simplemente no sabemos cómo lo hace realmente, es por eso que no tiene sentido. –

Cuestiones relacionadas