错误的GWT请求对象列表的工厂性能

Question

我正在通过GWT Request Factory将对象列表传输到客户端.对象只包含几个字符串,列表只包含20个对象.要传输这个小数据列表,需要一秒钟.首先,我认为需要优化查询.但测量显示:

从数据库中检索对象只需要

300ms

转移到客户端总共需要一秒钟

1136ms

所以这似乎是请求工厂开销.我已经使用了自己的ServiceLayerDecorator并且已经覆盖了isLive()函数,所以它总是返回true.我可以采取任何其他措施加快速度并将性能提升到可接受的范围吗？

更新:

我创建了将我的实体对象数据复制到DTO并使用RPC传输它们以比较RPC和Request工厂性能的逻辑.如您所见,RPC逻辑要快得多.现在我想知道这是设计还是我的申请中存在缺陷.

20个转移对象:

Request factory: 1252 ms

RPC: 420 ms

28个转移对象:

Request factory: 1654 ms

RPC: 460 ms

78个转移对象:

Request factory: 3963 ms

RPC: 769 ms

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

UPDATE2

所以我编写了一个非常简单的示例应用程序,以确保我的应用程序没有任何过滤器或其他干扰组件.应用程序从服务器加载10个带有4个String字段的对象.我使用Request工厂和RPC完成了它并停止了时间.

代码可以在这里找到:https: //github.com/jan10101/requstFactoryVSRPC

这里的生活演示:http: //requestfactorytest.appspot.com/

测试应用程序证实了我的观察结果:与RPC性能相比,请求工厂性能非常糟糕.在开发模式下,RPC的性能大约高出40倍,在生产模式下仍然是4倍.我是第一个注意到性能问题的人吗？

以下屏幕截图显示了测试结果,如果您不想自己尝试.

开发模式下的结果:

生产代码的结果(在app引擎上):

Answer 1

我不确定这与您的具体情况有多大相关性，但问题可能是 AutoBeans。RequestFactory 广泛使用 AutoBeans。

我最近能够通过减少 AutoBeans 的使用来解决 GWT 应用程序中的性能问题，这似乎非常慢。使用分层性能分析器（例如 IE 的 F12 工具中的分析器）将 Autobean 代码确定为问题的根源，因此性能问题出在客户端。IIRC 解决方案是在调用完成后将 AutoBeans 复制到“真实”Java 对象。