GWT Requestfactory性能建议 [英] GWT Requestfactory performance suggestions

问题描述

使用GWT requestfactory时，我观察到了糟糕的性能。例如，一个将我的服务层2秒传递给fullfil的请求将GWT花费20秒来序列化。我的服务正在返回〜100什么是EntityProxies。这些对象中的每一个都有4个ValueProxies和2个EntityProxies（100个根级别的EntityProxies，400个ValueProxies和200个额外的EntityProxies）。然而，在小得多的数据集中，我看到相同的10倍性能下降。

日志片段示例：

<$ p $服务层调用：调用服务层花了2265 ms
D 2012-10-18 22:42：58.957 RequestFactoryServlet doPost：整个请求花费了22870美元ms

我已将一些分析代码添加到 ServiceLayerDecorator＃invoke 方法并将整个servlet包装在一个计时器中。我已经自己介绍了这项服务，它的确在2秒内返回结果。

我正在使用GWT 2.4，但已经在GWT 2.5rc1和GWT 2.5rc2上测试过了。我的后端位于GAE，但我不认为这是在这里扮演的角色。

我发现这个bug对2.4提起，这似乎是非常相关的。我手动应用了来自此Google群组没有任何运气。

我的域模型看起来像：

  class Trip {
受保护的地址来源; //变成ValueProxy 
保护地址目的地;成为ValueProxy 
受保护设置< TripPassenger> tripPassengers; // Set ValueProxies 
} 
 
 class TripPassenger {
受保护的乘客; 
} 
 
类乘客{
受保护帐户; 
} 
  

我的问题是：

• 我是否正确地分析了代码并将问题隔离到了GWT序列化中？


• 我可能会做出会导致此行为的错误吗？
li>

• 如何更好地描述GWT序列化代码以找出原因？

解决方案

• 我是否正确地分析了代码并将问题隔离到了GWT序列化中？

RequestFactory使用反射很多（比GWT-RPC多得多），所以我并不感到惊讶它在某些情况下会导致一些性能问题。 GA $可以在这里发挥作用。

我相信RequestFactory（实际上是AutoBean的一部分）可以在构建时从代码生成中获益。

• 我可能会做出会导致此行为的错误吗？

检查你的定位器 find 和/或 isLive 方法。

• 如何更好地分析GWT序列化代码以找出原因？
  ul>
  

知道请求反序列化，应用更改以及序列化响应的时间也很有趣。不要忘记减去在 find 和 isLive 中花费的时间。

I am observing really bad performance when using GWT requestfactory. For example, a request that takes my service layer 2 seconds to fullfil is taking GWT 20 seconds to serialize. My service is returning ~100 what will be EntityProxies. Each of these objects has what will become 4 ValueProxies and 2 more EntityProxies (100 root level EntityProxies, 400 ValueProxies and 200 additional EntityProxies). However, I see the same 10x performance degradation on much smaller datasets.

Example of log snippet:

D 2012-10-18 22:42:39.546 ServiceLayerDecorator invoke: Inoking service layer took 2265 ms
D 2012-10-18 22:42:58.957 RequestFactoryServlet doPost: Entire request took 22870 ms

I have added some profiling code to the ServiceLayerDecorator#invoke method and wrapped the entire servlet in a timer. I have profiled the service by itself, and it is indeed returning results in ~2s.

I am using GWT 2.4, but have tested this on GWT 2.5rc1 and GWT 2.5rc2. My backend is on GAE, but I dont think that is playing a role here.

I found this bug filed against 2.4, which seems to be very related. I have manually applied the patch from this google group without any luck.

My domain models look like:

class Trip {
  protected Address origin; // becomes ValueProxy
  protected Address destination; becomes ValueProxy
  protected Set<TripPassenger> tripPassengers; // Set of ValueProxies
}

class TripPassenger {
  protected Passenger passenger;
}

class Passenger {
  protected Account account;
}

My question is:

• Have I profiled the code correctly and isolated the problem to the GWT serialization?
• Could I be doing something wrong that would cause this behavior?
• How can I better profile the GWT serialization code to try and figure out the cause?

解决方案

• Have I profiled the code correctly and isolated the problem to the GWT serialization?

RequestFactory uses reflection a whole lot (much more than GWT-RPC for instance), so I'm not really surprised that it causes some perf issues in some cases. And GAE could play a role here.
I believe RequestFactory (the AutoBean part actually) could greatly benefit from code generation at build-time.

• Could I be doing something wrong that would cause this behavior?

Check your locators' find and/or isLive methods.

• How can I better profile the GWT serialization code to try and figure out the cause?

It would also be interesting to know the time spent on deserialization of the request, applying changes, and then serialization of the response. And don't forget to substract from those the time spent in find and isLive.

这篇关于GWT Requestfactory性能建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！