錯誤的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對象。