我正在评估使用 GWT-RPC 和HTTP Call进行的调用之间是否存在性能差异。
我的 appln 服务托管为 Java servlet,我目前正在使用 HTTPProxy 连接从中获取数据。如果这会带来性能改进,我希望将它们转换为 GWT-RPC 调用。
我想知道每个人的优缺点...
还有关于测量异步调用性能的工具的任何建议......
[一篇关于可以与 GWT 一起使用的各种服务器通信策略的好文章。]
我正在评估使用 GWT-RPC 和HTTP Call进行的调用之间是否存在性能差异。
我的 appln 服务托管为 Java servlet,我目前正在使用 HTTPProxy 连接从中获取数据。如果这会带来性能改进,我希望将它们转换为 GWT-RPC 调用。
我想知道每个人的优缺点...
还有关于测量异步调用性能的工具的任何建议......
[一篇关于可以与 GWT 一起使用的各种服务器通信策略的好文章。]
当后端也用 Java 编写时,通常首选 GWT-RPC,因为这意味着不必在每一端对对象进行编码和解码——您只需将常规 Java 对象传输到客户端,并在那里使用它。
JSON(使用RequestBuilder
)通常在后端使用其他语言编写时使用,并且需要服务器对响应对象进行 JSON 编码,并要求客户端将其 JSON 解码为JavaScriptObject
用于 GWT 代码的。
如果我不得不猜测,我会说 GWT-RPC 也会产生更小的传输对象,因为 GWT 团队针对这种情况进行了优化,但两者都可以,而且 JSON 仍然可以很小。在大多数情况下,这只是为了方便开发人员。
至于测量请求时间的工具,您可以使用 Chrome/Webkit 的开发人员工具,或 Firefox 的 Firebug 扩展,或者在您的应用程序中测量请求时间,并将该指标数据以延迟请求的形式发送回您的服务器以进行收集和分析。
我写了问题中提到的那篇文章(感谢链接!)。
与往常一样,答案是“视情况而定”。我使用过 GWT-RPC 和 JSON。
如上所述,GWT-RPC 允许通过网络传输 Java 对象(有一些限制)具有一定的生产力。一些逻辑可以共享,GWT 负责编组/解组您的对象。
JSON 允许其他非 GWT 客户端进行跨域访问和使用。您可以使用覆盖类型,但不能共享任何行为(如验证)。JSON 也可以很容易地压缩和缓存,这与 GWT-RPC(我上次查看)不同。
由于我们不知道有效载荷是什么,因此很难给出性能建议。我建议(再次,正如上面有人所做的那样)测试自己。
只是对其他答案的补充,有一点需要考虑,这可能会影响您对 JSON 的决定,即使您在后端使用 Java:
也许在未来的某个时候,您希望允许非 GWT 客户端与您的服务器通信。许多现代网站提供某种 API 访问,如果您使用 JSON,那么您基本上已经拥有一个相对开放的 API。
一般来说,我同意 Jason - 如果您的服务器端使用 Java,请使用 GWT-RPC。您将能够重用 POJO、验证逻辑等。RPC 也倾向于更好地“发挥”MVP 和代码拆分。
但是,如果您的服务器端使用其他任何东西,请使用 JSON - 但不要担心,使用 JSON 的JavaScript 覆盖类型是轻而易举的事。但是,您将无法在服务器上重用来自客户端的代码(YMMV)。
从性能的角度来看 - 我会说 JSON 在这里具有优势。现代浏览器有一些非常好的方法来对 JSON 进行快速编码/解码。我不确定 GWT-RPC 是什么“幕后”,但我怀疑它在速度方面能否击败 JSON。至于有效负载 - 这取决于开发人员(JSON 中的对象名称等),但我想说的是,通常 JSON 也(略微)更小。在您的服务器上启用压缩(例如,Apache HTTP 上的 mod_deflate)以进一步压缩位;)