Comparación de rendimiento de Thrift, Protocol Buffers, JSON, EJB, otros?

StackOverflow https://stackoverflow.com/questions/296650

Pregunta

Estamos buscando soluciones de transporte / protocolo y estábamos a punto de hacer varias pruebas de rendimiento, así que pensé en consultar con la comunidad si ya lo habían hecho:

¿Alguien ha realizado pruebas de rendimiento del servidor para servicios de eco simples, así como serialización / deserialización para varios tamaños de mensajes comparando EJB3, Thrift y Protocol Buffers en Linux?

Principalmente los lenguajes serán Java, C / C ++, Python y PHP.

Actualización: Todavía estoy muy interesado en esto, si alguien ha hecho más puntos de referencia, hágamelo saber. Además, un punto de referencia muy interesante que muestra JSON comprimido con un rendimiento similar / mejor que Thrift / Protocol Buffers , así que yo Estoy lanzando JSON a esta pregunta también.

¿Fue útil?

Solución

Última comparación disponible aquí en el wiki del proyecto thrift-protobuf-compare . Incluye muchas otras bibliotecas de serialización.

Otros consejos

Estoy en el proceso de escribir un código en un proyecto de código abierto llamado thrift -protobuf-compare comparando entre protobuf y thrift. Por ahora cubre algunos aspectos de serialización, pero tengo la intención de cubrir más. Los resultados (para Thrift y Protobuf ) se discuten en mi blog, agregaré más cuando llegue a él. Puede mirar el código para comparar API, lenguaje de descripción y código generado. Estaré encantado de tener contribuciones para lograr una comparación más completa.

Probé el rendimiento de PB con varios otros formatos de datos (xml, json, serialización de objetos predeterminada, hessian, uno patentado) y bibliotecas (jaxb, infoset rápido, escrito a mano) para tareas de enlace de datos (tanto lectura como escritura), pero no se incluyeron los formatos de ahorro. El rendimiento para formatos con múltiples convertidores (como xml) tuvo una variación muy alta, desde muy lenta hasta bastante rápida. La correlación entre las afirmaciones de los autores y el rendimiento percibido fue bastante débil. Especialmente para los paquetes que hicieron reclamos más salvajes.

Por lo que vale, descubrí que el rendimiento de PB está un poco exagerado (generalmente no por sus autores, sino por otros que solo saben quién lo escribió). Con la configuración predeterminada, no superó la alternativa textual xml más rápida. Con el modo optimizado (¿por qué no es esto predeterminado?), Fue un poco más rápido, comparable con el paquete JSON más rápido. Hessian era bastante rápido, textual json también. El formato binario apropiado (sin nombre aquí, era interno de la compañía) fue el más lento. La serialización de objetos de Java fue rápida para mensajes más grandes, menos para objetos pequeños (es decir, alto encabezado fijo por operación). Con PB, el tamaño del mensaje era compacto, pero teniendo en cuenta todas las compensaciones que tiene que hacer (los datos no se autodescriben: si pierde el esquema, pierde datos; hay índices, por supuesto, y tipos de valores, pero de lo que tiene si lo desea, haga ingeniería inversa a los nombres de los campos), personalmente solo lo elegiría para casos de uso específicos: un sistema sensible al tamaño y estrechamente acoplado donde la interfaz / formato nunca (o muy raramente) cambia.

Mi opinión en esto es que (a) la implementación a menudo importa más que la especificación (del formato de datos), (b) de extremo a extremo, las diferencias entre los mejores (para diferentes formatos) generalmente no son lo suficientemente grandes para dictar la elección. Es decir, es mejor que elija el formato + API / lib / framework que más le guste (o tenga la mejor compatibilidad con herramientas), encuentre la mejor implementación y vea si eso funciona lo suficientemente rápido. Si (¡y solo si!) No, considere la siguiente mejor alternativa.

ps. No estoy seguro de cuál sería EJB3 aquí. ¿Tal vez simplemente por la serialización de Java?

Una de las cosas cerca de la parte superior de mi " to-do " La lista de PBs es portar el punto de referencia de rendimiento interno del Buffer de Protocolo de Google: se trata principalmente de tomar formatos de mensajes confidenciales y convertirlos en completamente insípidos, y luego hacer lo mismo con los datos.

Cuando haya terminado, me imagino que podrías crear los mismos mensajes en Thrift y luego comparar el rendimiento.

En otras palabras, aún no tengo los datos para usted, pero espero que en las próximas dos semanas ...

Si el rendimiento neto bruto es el objetivo, entonces nada supera a IIOP (ver RMI / IIOP). La huella más pequeña posible: solo datos binarios, sin marcado en absoluto. La serialización / deserialización también es muy rápida.

Como es IIOP (es decir, CORBA), casi todos los idiomas tienen enlaces.

Pero supongo que el rendimiento no es el único requisito, ¿verdad?

Para respaldar el punto de Vladimir sobre IIOP, aquí hay una prueba de rendimiento interesante, que debería proporcionar información adicional sobre los puntos de referencia de Google, ya que compara Thrift y CORBA. (Performance_TIDorb_vs_Thrift_morfeo.pdf // el enlace ya no es válido) Para citar del estudio:

  
      
  • Thrift es muy eficiente con pequeños   datos (tipos básicos como operación   argumentos)
    •   
  • Los transportes de segunda mano no son tan eficientes como CORBA con medios y   datos grandes (estructura y > complejo   tipos > 1 kilobytes).
    •   

Otra limitación extraña, que no tiene que ver con el rendimiento, es que Thrift se limita a devolver solo varios valores como estructura, aunque esto, como el rendimiento, seguramente puede mejorarse.

Es interesante que el Thrift IDL coincida estrechamente con el CORBA IDL, bueno. No he usado Thrift, parece interesante especialmente para mensajes más pequeños, y uno de los objetivos de diseño era una instalación menos engorrosa, por lo que estas son otras ventajas de Thrift. Dicho esto, CORBA tiene una mala reputación, hay muchas implementaciones excelentes como omniORB por ejemplo, que tiene enlaces para Python, que son fáciles de instalar y usar.

Editado: el enlace Thrift y CORBA ya no es válido, pero encontré otro documento útil del CERN. Evaluaron reemplazos para su sistema CORBA y, mientras evaluó Thrift , finalmente se fueron con ZeroMQ. Si bien Thrift realizó el más rápido en sus pruebas de rendimiento, a 9000 msg / seg frente a 8000 (ZeroMQ) y 7000+ RDA (basado en CORBA), eligieron no probar Thrift más debido a otros problemas, en particular:

  

Sigue siendo un producto inmaduro con una implementación defectuosa

He realizado un estudio para la integración de Spring-boot, mappers (manual, Dozer y MapStruct), Thrift, REST, SOAP y Protocol Buffers para mi trabajo.

El lado del servidor: https://github.com/vlachenal/webservices-bench

El lado del cliente: https://github.com/vlachenal/webservices-bench-client

No está terminado y se ejecutó en mis computadoras personales (tengo que pedir servidores para completar las pruebas) ... pero los resultados se pueden consultar en:

Como conclusión:

  • Thrift ofrece el mejor rendimiento y es fácil de usar
  • El servicio web RESTful con tipo de contenido JSON está bastante cerca del rendimiento de Thrift, está "listo para usar" en el navegador. y es bastante elegante (desde mi punto de vista)
  • SOAP tiene un rendimiento muy pobre pero ofrece el mejor control de datos
  • Protocol Buffers tiene un buen rendimiento ... hasta 3 llamadas simultáneas ... y no sé por qué. Es muy difícil de usar: me doy por vencido (por ahora) para que funcione con MapStruct y no lo intento con Dozer.

Los proyectos se pueden completar mediante solicitudes de extracción (ya sea para arreglos u otros resultados).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top