performance - ¿El rendimiento de Erlang(o elixir)(solicitudes por segundo) es lento frente a jruby?

webmachine requests-per-second (3)

Siendo un rubí, decidí tomar Erlang para un backend confiable y de alto rendimiento. La configuración es bastante simple: obtener una solicitud de publicación, escribir cosas para redisponer, devolver estadísticas. Todo json. Esta es la razón por la que me importan tanto las solicitudes por segundo.

Herramientas de elección: webmachine , jiffy para la codificación / decodificación json, poolboy para el grupo de conexiones, y eredis para la comunicación de redis.

Máquina utilizada: macbook pro, i5 2.4GHz, 8GB de memoria.

Mi erlang obtuvo alrededor de 5000 solicitudes por segundo, y el jruby / torqbox obtuvo aproximadamente 12,0000. ( mira aquí para una configuración completa de prueba de rendimiento rubí )

Me doy cuenta de que podría usar ets en erlang para ahorrar tiempo, y dejar el redis para que se escriba "procesamiento en segundo plano" después de la respuesta, pero esto tendrá poco impacto. incluso una simple prueba de ''hola mundo'' erlang piernas detrás.

¿Alguna sugerencia? ¿Lo estoy haciendo mal?

FYI: "+ A 100" no ayudaría con la red, es solo para archivos IO. Si realmente desea un servidor web rápido, visite github.com/knutin/elli y le dará 80 kprs en el hardware donde el vaquero le dará 30 krps. Por otro lado, elli es algo que muchas personas están culpando por no seguir los principios de la PTO.

jiffy es una buena opción si puede colocar un equilibrador de carga para desinfectar las solicitudes, ya que jiffy introducirá segfaults en su código; eche un vistazo a la lista de problemas.

de todos modos, erlang no es algo que deba elegir si todo lo que necesita es realmente rápido GET -> decodificar json -> store -> REPLY workload.

Mis 2 centavos. Tienes el extremo equivocado del palo. Está probando un problema para el que la JVM está optimizada en un tipo de máquina en la que la JVM está optimizada para trabajar.

Realmente no vas a ver las ventajas de Erlang / OTP en la cantidad de núcleos disponibles en un Mac Book Pro. Esta es solo una suposición aproximada, pero me sorprendería ver a Erlang venciendo a la JVM en cualquier cosa que no sea un servidor de 8 núcleos. Ha habido un gran número de horas / hombre dedicados a hacer la JVM lo más rápido posible en el hardware actual.

Escribir código de E / S seguro para subprocesos es bastante sencillo, los problemas reales surgen cuando se trata de acceso a la memoria entre decenas y cientos de subprocesos.

Escribir en Erlang / Elixir apunta al servidor de gama alta actual de 16 o 32 núcleos con el potencial de escalar mucho más en el futuro cercano.

Webmachine - No lo sé. Es bastante pesado para mi gusto y no lo uso.
jiffy - buena elección Bastante rápido y lo uso mucho.
poolboy - No me enteré y estoy cerca de Erlang durante varios años. Definitivamente usaría cowboy para cualquier cosa que esperaría de alto rendimiento o yaws para un poco más de roca sólida pero que todavía tenga un buen desempeño. Para su punto de referencia es la elección correcta del vaquero, es el mejor rendimiento.
eredis - No sé cuán madura y eficiente es. Es más apropiado para el benchmark. Para su prueba de macbook, no importa, pero para el servidor grande (decenas de CPU), comprobaría si ti no es un cuello de botella y una tabla de particiones.
lo más importante es comprobar los parámetros de su VM. Al menos debería tener +K true +A 100 para este tipo de carga.

Su resultado para Erlang parece simplemente demasiado bajo en comparación con la experiencia de la mina. Deberías ser casi diez veces más grande. También puede haber un problema con su herramienta de generación de carga útil.

Y sobre todo importante, esto puede ser considerado no solo como un micro benchmark para el mundo de Erlang, sino que puede ser nano o un benchmark. La verdadera fuerza revelará cuando intentarás algo más difícil y más complicado. Algo en el que la solicitud concurrente debe afectarse mutuamente de una manera muy complicada y debe lidiar con la eventualidad de la coherencia e implementarla de manera mucho más escalable y necesita utilizar comunicación entre procesos asíncrona.