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

Question

Estamos buscando soluciones de transporte/protocolo y estamos a punto de hacer varias pruebas de rendimiento, así que pensé en verificar con la comunidad si ya lo han hecho:

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

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

Actualización: Todavía estoy muy interesado en esto, si alguien ha hecho otros puntos de referencia por favor hágamelo saber. Además, punto de referencia muy interesante que muestra compressed JSON performing similar/better than Thrift/Protocol Buffers, así que estoy lanzando JSON en esta cuestión también.

Answer 1

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

Answer 2

Usted puede estar interesado en esta pregunta: "Biggest differences of Thrift vs Protocol Buffers?"

Answer 3

Una de las cosas cerca de la parte superior de mi lista de "cosas por hacer" para PBS es puerto de protocolo de referencia de rendimiento Buffer interno de Google - es sobre todo un caso de tomar formatos de mensajes confidenciales y convirtiéndolos en unos completamente insulsos, y luego haciendo lo mismo con los datos.

Cuando se haya hecho eso, me imagino que podría compilar los mismos mensajes en Thrift y luego comparar el rendimiento.

En otras palabras, no tengo los datos para que todavía - pero espero que en el próximo par de semanas ...

Answer 4

Si el rendimiento neto de crudo es el objetivo, entonces no hay nada como IIOP (RMI veo/IIOP). Huella mínima posible: solo datos binarios, sin marcado. La serialización/deserialización es muy rápida también.

Dado que es IIOP (que es CORBA), casi todos los idiomas tienen enlaces.

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

Answer 5

Estoy en el proceso de escribir un código en un open source project named thrift-protobuf-compare comparando entre protobuf y ahorro. Por ahora, cubre algunos aspectos de serialización, pero pretendo cubrir más. Los resultados (para Thrift y Protobuf) se discuten en mi blog, añadiré más cuando lo encuentre. Puede consultar el código para comparar la API, el lenguaje de descripción y el código generado. Estaré encantado de tener contribuciones para lograr una comparación más completa.

Answer 6

Realicé pruebas de rendimiento de PB con otros formatos de datos (xml, json, serialización de objetos por defecto, hessian, uno patentado) y bibliotecas (jaxb, infoset rápido, escritas a mano) para tareas de enlace de datos (ambas leyendo y escritura), pero el/los formato (s) de ahorro no se incluyeron. El rendimiento para formatos con múltiples convertidores (como xml) tuvo una variación muy alta, desde muy lento hasta bastante rápido. 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 descabellados.

Por lo que vale, encontré que el rendimiento de PB era 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 el predeterminado?), Era un poco más rápido, comparable con el paquete JSON más rápido. Hessian era bastante rápido, json textual también. El formato binario apropiado (sin nombre aquí, era interno de la empresa) era el más lento. La serialización de objetos Java fue rápida para mensajes más grandes, y menos para objetos pequeños (es decir, alto número fijo por operación no reparado). Con el tamaño del mensaje PB era compacto, pero teniendo en cuenta todas las compensaciones que tiene que hacer (los datos no son autodescriptivos: si pierde el esquema, pierde datos, hay índices de curso y tipos de valor, pero de lo que tener retroingeniería de regreso a los nombres de campo si lo desea), yo personalmente solo lo elegiría para casos de uso específicos: sensible al tamaño, sistema estrechamente acoplado donde la interfaz/formato nunca (o muy raramente) cambia.

Mi opinión es que (a) la implementación a menudo es más importante que la especificación (del formato de datos), (b) de extremo a extremo, las diferencias entre los mejores (generalmente no son grandes) lo suficiente como para dictar la elección. Es decir, es mejor que elija el formato + API/lib/framework que más le gusta usar (o tiene la mejor herramienta de soporte), encuentre la mejor implementación y vea si funciona lo suficientemente rápido. Si (¡y solo si!) No, considere la siguiente mejor alternativa.

ps. No estoy seguro de qué EJB3 sería aquí. ¿Tal vez simplemente de la serialización de Java?

Answer 7

Para respaldar el punto de Vladimir sobre IIOP, esta es 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 // enlace ya no es válido) citar el estudio:

• ahorro es muy eficiente con pequeñas datos (tipos básicos como la operación argumentos)
• cajas de ahorro transportes no son tan eficiente como CORBA con medio y datos grandes (struct y> tipos complejos > 1 kilobytes).

Otra limitación extraña, que no tenga que ver con el rendimiento, es que Thrift se limita a devolver varios valores solamente como una estructura - a pesar de esto, como el rendimiento, sin duda puede ser mejorado, tal vez.

Es interesante que el Thrift IDL coincida estrechamente con el IDL de CORBA, lindo. No he usado Thrift, parece interesante especialmente para mensajes más pequeños, y uno de los objetivos de diseño fue para 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 de Ahorro y CORBA ya no es válido, pero encontré otro documento útil del CERN. Evaluaron reemplazos para su sistema CORBA, y, mientras ellos evaluated Thrift, eventualmente fueron con ZeroMQ. Mientras Thrift realizó el más rápido en sus pruebas de rendimiento, en 9000 msg/seg vs 8000 (ZeroMQ) y 7000+ RDA (CORBA-based), han optado por no poner a prueba Thrift aún más debido a otras cuestiones en particular:

todavía es un producto inmaduro con una aplicación con errores

Answer 8

he hecho un estudio para la primavera-bota, cartógrafos (manual, dormilón y MapStruct), Thrift, REST, SOAP y la integración 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 ha ejecutado en mis ordenadores personales (tengo que pedir servidores para completar las pruebas), pero ... Los resultados pueden consultarse en:

• portátil: https://github.com/vlachenal/webservices-bench/blob/master/results.md
• escritorio: https://github.com/vlachenal/webservices-bench/blob/master/results-desktop.md

Como conclusión:

• Thrift ofrece el mejor rendimiento y es fácil de usar
• servicio web REST con JSON tipo de contenido está bastante cerca de rendimiento Thrift, es "navegador listo para usar" 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 rindo (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 soluciones u otros resultados).