what protocol protobuf google buffers array java python performance protocol-buffers thrift

java - protobuf - protocol buffers array



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

Estoy en proceso de escribir un código en un proyecto de código abierto llamado thrift-protobuf-compare que compara protobuf y thrift. Por ahora, cubre algunos aspectos de serialización, pero pretendo cubrir más. Los resultados (para Thrift y Protobuf ) se discuten en mi blog, Protobuf más cuando lo encuentre. Puede mirar 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.

Estamos investigando soluciones de transporte / protocolo y estábamos a punto de hacer varias pruebas de rendimiento, así que pensé en verificar con la comunidad si ya han hecho esto:

¿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 que comparen EJB3, Thrift y Buffers de protocolo 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 algún punto de referencia adicional por favor hágamelo saber. Además, un punto de referencia muy interesante que muestra que JSON comprimido tiene un rendimiento similar / mejor que Thrift / Protocol Buffers , así que también estoy lanzando a JSON a esta cuestión.

He realizado un estudio para la integración de spring-boot, mapeadores (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 ha ejecutado 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 el tipo de contenido JSON está bastante cerca del rendimiento de Thrift, es "navegador listo para usar" y es bastante elegante (desde mi punto de vista)
  • SOAP tiene un rendimiento muy bajo 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 a través de solicitudes de extracción (ya sea para soluciones u otros resultados).

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

Para respaldar el punto de Vladimir sobre IIOP, aquí hay una prueba de rendimiento interesante, que debería dar alguna 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 argumentos de operación)
  • Los transportes Thrifts no son tan eficientes como CORBA con datos medianos y grandes (struct y> tipos complejos> 1 kilobytes).

Otra limitación extraña, que no tiene que ver con el rendimiento, es que Thrift está limitado a devolver solo varios valores como una estructura, aunque esto, al igual que el rendimiento, seguramente puede mejorarse.

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 los reemplazos para su sistema CORBA, y, mientras evaluaban Thrift , finalmente se fueron con ZeroMQ. Mientras que Thrift realizó el más rápido en sus pruebas de rendimiento, a 9000 msg / seg vs. 8000 (ZeroMQ) y 7000+ RDA (basado en CORBA), optaron por no probar Thrift aún más debido a otros problemas notablemente:

Todavía es un producto inmaduro con una implementación defectuosa

Probé el 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 (tanto de lectura como de escritura), pero el formato (s) de ahorro no fue incluido. 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). Con PB el tamaño del mensaje 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 tiene aplicar ingeniería inversa a los nombres de campo si lo desea), yo personalmente solo lo elegiría para casos de uso específicos: sistema sensible al tamaño, estrechamente acoplado, donde la interfaz / formato nunca (o muy raramente) cambia.

Mi opinión al respecto 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 (por diferentes formatos) generalmente no son lo suficientemente grandes como para dictar el elección. Es decir, es mejor que elija el formato + API / lib / framework que más le gusta usar (o que tenga la mejor compatibilidad con herramientas), encuentre la mejor implementación y vea si funciona lo suficientemente rápido. Si (¡y solo si!) No, considere la siguiente mejor alternativa.

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

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

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

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

Una de las cosas más importantes de mi lista de "tareas pendientes" para PBs es utilizar el benchmark interno de desempeño de Buffer de Protocolo de Google. Se trata principalmente de tomar formatos de mensajes confidenciales y convertirlos en formatos completamente simples, y luego hacer lo mismo para los datos.

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

En otras palabras, todavía no tengo los datos para ti, pero espero que en las próximas semanas ...