Comparación de rendimiento de los servidores web RPi 3: Apache, Nginx y Lighttpd

11

¿Alguien ha hecho alguna prueba de comparación de rendimiento real en RPi 3 en servidores web populares:

  1. Apache2 : el servidor más frecuente
  2. Nginx : el servidor que afirma tener el mejor rendimiento
  3. Lighttpd : el servidor más ligero
  4. O un paquete del que no he oído hablar

Algo así como esta publicación de 4 años para el RPi 2 . Siguiendo el consejo de esa publicación, amplié mi investigación de manera más general y encontré este artículo , pero lo considero un poco sospechoso, ya que es una empresa de hosting, y necesito una respuesta adaptada al hardware del RPi 3.

web-server apache-httpd lighttpd Sandor Dosa
fuente
44
Fuera del tema: No entiendo por qué alguien rechaza una pregunta sin dar una pista de lo que está mal.
Joe Platano
2
No soy pasivo agresivo ni busco que elimines tu pregunta. En ese momento estaba demasiado ocupado para publicar un comentario explicando mi voto negativo. El primer problema es que estás optimizando prematuramente. No ha definido claramente el caso de uso (qué módulos / funcionalidad se necesitarán, etc.). Podría continuar con varios párrafos más, pero dejaré que sus propias palabras hablen por sí mismas: "Si Nginx hará lo que necesito, entonces parece ser un mejor producto listo para usar (o no apto) -get) solución para armar antes de que comiencen los ajustes de rendimiento ".
Steve Robillard
2
Si Nginx hace lo que necesito (por lo que puede descartar uno o más de los servidores en función de los requisitos; por lo tanto, su pregunta es irrelevante. Está colocando el carro antes que el caballo. Obtenga un sistema que funcione y luego preocúpese por ajuste de rendimiento. En segundo lugar, para responder a su pregunta dependerá de la carga de trabajo específica, ¿el uso de la base de datos se leerá o escribirá mucho? ¿El sistema estará vinculado a la base de datos o IO? para ayudar.
Steve Robillard
2
Una vez más, citando que "poder servirles a todos algo sin una gran cantidad de retraso es importante". ¿Cuánto es demasiado retraso? y, por último, "He visto otras publicaciones sobre cómo ajustar Apache y Nginx para un mejor rendimiento, pero eso parece mucho trabajo solo para construir una configuración de prueba para comparar las opciones". ¿No es esto exactamente lo que le estás pidiendo a alguien que haga por ti en esta pregunta? Sin el beneficio de datos de tráfico reales o una especificación completa del problema. Sin estas cosas, también pueden consultar una bola de cristal.
Steve Robillard
Teniendo en cuenta la huella de memoria y las limitaciones del procesador del PI, ¿no sería algo más útil una configuración basada en nodos junto con express en un servidor impulsado por eventos IO sin bloqueo? De nuevo, depende de su caso de uso. ¿Está sirviendo archivos estáticos o archivos dinámicos? Es su pan para tener una aplicación web o un sitio web.
CoderX

Respuestas:

5

Esto debería ser un comentario, pero es un poco largo.

Si bien (todavía) no he probado varios servidores web en mi Pi, anteriormente he realizado muchas pruebas en servidores web que se ejecutan en hardware de servidor x86. Lo que sé de allí es:

  1. la mayoría de las personas se confunden acerca de la diferencia entre rendimiento y capacidad: verá muchas publicaciones que afirman que nginx es más rápido que el apache (previo a la bifurcación), esto no es cierto , excepto bajo una gran carga. Nginx (y lighty) son mucho mejores en capacidad. Y ese es el nivel de análisis más trivial.

  2. Pocas personas ofrecen contenido exclusivamente estático con sus servidores web (en este escenario, tux y G-Wan dejan los servidores que has mencionado en su polvo). El perfil de rendimiento depende en gran medida de la tecnología de nivel lógico y su integración con el servidor web.

  3. El rendimiento (y la capacidad) depende de todo lo demás que se ejecute en el dispositivo.

Hay muchas características de un servidor de centro de datos que son muy fáciles de vivir sin tener una redundancia adecuada de nivel de clúster (doble psu, doble red, consola remota ...), sin embargo, un Raspberry PI no tiene el mejor sentido como una web plataforma de servicio debido a E / S de disco lento: realmente necesita algo con conectividad SATA, [i] SCSI, AOE o infiniband para su almacenamiento. El Pi no tiene una interfaz SATA, solo tiene un puerto ethernet y no conozco una interfaz infiniband o SCSI.

(hay computadoras pequeñas, de placa única, que son una opción más sensata para desarrollar la capacidad de servicio web, y un grupo de estas puede tener un buen sentido económico, pero en tal escenario, está viendo múltiples nodos con capacidad en capas para la terminación SSL, HTTP almacenamiento en caché, servicio web, lógica de aplicaciones y gestión de datos).

La cuestión del más rápido es difícil de definir, diferente para cada caso e imposible de responder.

Sin embargo, el error más grande que veo una y otra vez en TI es que las personas eligen productos en función de un solo atributo en lugar de considerar el impacto más amplio tanto en términos de tecnología como de personas involucradas.

symcbean
fuente
Buenos puntos todos. Me temo que este proyecto se ha recuperado.
Sandor Dosa
2

Me temo que necesitas averiguarlo por tu cuenta. Cuando tuve esta pregunta para mi RPi2, me topé con Siege y httperf . Seguí este ejemplo para ejecutar los puntos de referencia: en lugar de páginas HTML simples, solicité archivos php. El rendimiento del servidor web también depende de los módulos cgi que elija. Un lighttpd simple de vainilla puede ser más rápido que un Apache de vainilla. Si está eligiendo / configurando el CGI incorrecto, esto podría cambiar y Apache puede superar al Lighty.

Joe Platano
fuente
Me temo que tienes razón. Comenzaré a tratar de resolver un método de prueba e informar de nuevo.
Sandor Dosa
@SandorDosa, mantenme al día, por favor
Joe Platano
2

Elegí la opción lighttpd, por las siguientes razones:

  1. ligero
  2. uno de los más fáciles de instalar
  3. funciona en mi RPi2 durante los últimos dos años sin ningún problema (24x7)
  4. necesitaba una buena y simple de usar como mi dispositivo de prueba

Lo uso como:

  1. supervisar la temperatura de la CPU de mi sistema, la temperatura ambiente / ambiente y el registrador gráfico de humedad
  2. Servidor FTP para intercambiar archivos con mis socios comerciales y evitar el almacenamiento de datos confidenciales en servidores de correo gratuitos de terceros
  3. Muchos widgets web para verificar el índice del mercado como forex, bonos, acciones, etc.
  4. prueba de código html
  5. ejecutar un script que hice para verificar el correo, ya que tengo muchas cuentas de correo, evitando bloqueos de geoetiquetado
  6. ejecutar un blog simple (blog de Nibble)
  7. trabajar como un honeypot para detectar (y bloquear) hackers en mi cable

solo por nombrar algunos usos.

JohnBR
fuente