java - Bad GWT Request Rendimiento de fábrica para la lista de objetos

performance gwt-rpc

Question

Estoy transfiriendo una lista de objetos al cliente con GWT Request Factory. Los objetos contienen solo un par de cadenas y la lista solo contiene 20 objetos. Para transferir esta pequeña lista de datos, toma más de un segundo. Primero pensé que la consulta debe ser optimizada. Pero la medida muestra:

La recuperación de los objetos de la base de datos solo toma

300ms

La transferencia al cliente toma en total más de un segundo

1136ms

Así que esto parece ser una solicitud de gastos generales de fábrica. Ya uso mi propio ServiceLayerDecorator y he anulado la función isLive() para que siempre sea true . ¿Hay alguna otra acción que pueda tomar para acelerar esto y llevar el rendimiento a un área aceptable?

Actualizar:

Creé la lógica para copiar los datos de mi objeto entidad a DTO y los transferí con RPC para comparar el RPC y solicitar el rendimiento de fábrica. Como puede ver, la lógica de RPC es mucho más rápida. Ahora me pregunto si eso es por diseño o si hay un defecto en mi aplicación.

20 objetos transferidos:

Request factory: 1252 ms

RPC: 420 ms

28 objetos transferidos:

Request factory: 1654 ms

RPC: 460 ms

78 objetos transferidos:

Request factory: 3963 ms

RPC: 769 ms

=============================================== ==========

Actualización2

Así que escribí una aplicación de muestra muy simple para asegurarme de que mi aplicación no tenga filtros u otros componentes que interfieran. Las aplicaciones cargan 10 objetos con 4 campos String del servidor. Lo hice con Request factory y RPC y detuve el tiempo.

El código se puede encontrar aquí: https://github.com/jan10101/requstFactoryVSRPC

Una demostración de vida aquí: http://requestfactorytest.appspot.com/

La aplicación de prueba confirma mi observación: el rendimiento de fábrica de la solicitud es realmente malo en comparación con el rendimiento de RPC. En el modo dev, el rendimiento de RPC es aproximadamente 40 veces mejor, en el modo de producción sigue siendo 4 veces. ¿Soy el primero en notar los problemas de rendimiento?

Las siguientes capturas de pantalla muestran los resultados de la prueba si no quiere probarlo usted mismo.

Resultados en modo dev:

Resultados del código productivo (en el motor de la aplicación):

Answer 1

No estoy seguro de qué tan relevante es esto para su caso específico, pero el problema puede ser AutoBeans. RequestFactory hace un uso extensivo de AutoBeans.

Recientemente pude resolver un problema de rendimiento en una aplicación GWT al reducir el uso de AutoBeans, que parecen ser muy lentos. El uso de un perfilador de rendimiento jerárquico como el de las herramientas F12 de IE identificó el código Autobean como la raíz del problema, por lo que el problema de rendimiento fue del lado del cliente. IIRC la solución fue copiar los AutoBeans a objetos Java "reales" después de la finalización de la llamada.