¿Cuál es la solución de servidor web más rápida con la huella de memoria más baja?

Question

Necesito un servidor web para servir solicitudes POST/GET muy simples como JSON. No necesito MVC, Rails, Django. Necesito algo que ocupe muy poca memoria, preferiblemente alrededor de 5 K por rendimiento. El servidor web hablará con servicios de back-end como Scribe usando Facebook Thrift. Cada solicitud http también accederá a una base de datos SQLLite, una para cada usuario y los datos del usuario no se superponen. Servirá archivos estáticos html, así como el servicio web json.

estoy considerando lo siguiente:

• Njinx con PHP,
• Kepler de Lua,
• rodar mi propia con libevent o libev quizás llamando a Lua, o
• MochiWeb.

¿Cuáles de estas opciones son las mejores y qué otras opciones existen? Puedo usar PHP, Python o Lua para scripting básico e incluso podría hacer C. Me estoy inclinando hacia algún tipo de solución de Erlang.

Answer 1

Lighttpd tiene una huella excelente, en la medida en que la mayor parte de su memoria probablemente será ocupada por el idioma que elija usar (a menos que vaya por la ruta C, que realmente no es recomendable).

Answer 2

Hay un artículo por IBM developerWorks con una muy extensa lista de servidores Web "ligeros":
Lightweight Web servers: http://www.ibm.com/developerworks/web/library/wa-ltwebserv/

Answer 3

que he tenido una buena experiencia con Nginx (http://nginx.net/), dicho esto, la hora de elegir un servidor web, debe analizar detenidamente sus requisitos y tomar una decisión informada, ya que estas cosas pueden ser muy específicas de la aplicación.

Notarás que en esta pregunta mucha gente recomienda g-wan, Webmachine, etc ... estas son todas las cosas que debes considerar y comparar para ver si son más rápidas para tu caso de uso.

Este es el tipo de pregunta que alienta a las porristas, no existe una "respuesta correcta".

Answer 4

Como mencionaste Python, tal vez quieras echar un vistazo a web.py, para escuchar de forma muy simple en el puerto 80 y asignar URL a las acciones.

También se ejecutará a través de su CGI favorito si desea vincularse con un servidor web estándar (es decir, detrás de Nginx/FastCGI) - y voy a segundo los recs de Nginx para concurrencia masiva en archivos estáticos. (Lo usaron con Lighttpd en Reddit.)

thttpd es el otro servidor web que vería, especialmente si la memoria es muy escasa, como en un sistema integrado.

Answer 5

Mochiweb es súper liviano y maneja una carga estúpidamente alta.

Answer 6

Como uno de los autores de Webmachine, me complace poder ayudarlo. Una de las razones por las que estoy haciendo un seguimiento es que, aunque no hay un código relacionado con JSON en Webmachine, puede resultar útil saber que lo usamos a diario para procesar muchas solicitudes y respuestas JSON diferentes. Es simple, limpiamente extensible y funciona razonablemente bien.

Si solo desea la entrega estática, entonces algo como nginx o lighttpd sería una forma obvia de hacerlo.Para una combinación de solicitudes estáticas y dinámicas y un buen comportamiento incorporado en la Web, puede encontrar que Webmachine es una buena opción.

Consulte el código de ejemplo trivial en http://code.google.com/p/webmachine/wiki/ExampleResources y las publicaciones recientes en el blog en http://blog.therestfulway.com/ para obtener más información.

Nos ha funcionado bien; si tiene alguna pregunta, no dude en escribirme un mensaje.

Answer 7

Cherokee servidor web en www.cherokee-project.com

Answer 8

Tome un vistazo a klone en koanlogic.com sitio ... está dirigida a los sistemas embebidos es muy pequeña, y de paso muy rápido también: http://john.freml.in/teepeedee2-vs-klone. Se puede escribir en C/C++ (rendimiento ultra) o PHP/CGI habitual (mucho menos rendimiento), según habilidades/gusto ...

Answer 9

Para medir la huella, observe el tamaño del ejecutable (no te olvides de las bibliotecas compartidas).

TrustLeap G-WAN (150 KB, sin dependencias) ofrece scripts Java, C/C++, Objective-C y D.

De acuerdo con estos puntos de referencia, sino que también utiliza menos recursos de memoria y CPU que Nginx o Lighttpd mientras se ejecuta más rápido:

http://www.gwan.ch/benchmark

Answer 10

Si podrían codificar en C o C++, creo lighttz sería el más rápido y usa la menor cantidad de memoria Sin embargo, la razón por la que es así es porque está usando libev y no tiene absolutamente nada, ni soporte de php, ni soporte html, nada. Todo lo que proporciona es una función de devolución de llamada donde maneja cada solicitud http. Tendrás que analizar la solicitud http GET/POST y devolver el html como una cadena. Puede ver que se compara con nginx, lighttpd, apache, etc. y aparece en la parte superior (link).

Answer 11

Puede echar un vistazo a FAPWS (Fast Asynchronous Python WSGI server). La filosofía del proyecto coincide perfectamente con sus necesidades. http://www.fapws.org

Answer 12

El servidor web incrustado más rápido es Snorkel - checkout existe el sitio web, destruyeron nginx en mis pruebas usando ab. http://sites.google.com/site/snorkelembedded

Answer 13

G-WAN (150 KB incluyendo scripts ANSI C) tiene un analizador JSON nativo, probablemente el más rápido disponible dadas las características (le permite buscar entradas por nombre o por valor además de importar/exportar desde/a texto)

Derribar la huella de 150 KB (servidor + script engine incluido) será difícil.

Answer 14

Eche un vistazo a this. Creo que esa es exactamente la información que estás buscando. No necesita un servidor web completo, por lo que usar Erlang + libevent/libev debería ser bueno.

Answer 15

Nginx se compara con Barniz (el caché utilizado por Facebook) y Apache tráfico del servidor (el caché utilizado por Yahoo!):

Y, Igor Sysoev, el hombre detrás de Nginx, no ha sido corta de comments on his blog.

Answer 16

Para C o Lua, Mongoose es una opción, https://github.com/valenok/mongoose. Utiliza más de 5k por solicitud, principalmente porque los datos por conexión tienen un búfer para la solicitud + encabezados preasignados, y el tamaño máximo de solicitud está establecido en 16k de manera predeterminada.Sin embargo, esto es sintonizable, no hay problema para que sea menos de 5k, simplemente cambie #define MAX_REQUEST_SIZE 16384 en mongoose.c cuando incruste Mongoose. En términos de espacio ocupado, se compilan alrededor de 50k en el disco sin contar Lua (en caso de que lo necesite) y SSL (también, en caso de que lo necesite). El espacio de tiempo de ejecución depende del sistema operativo.