我目前正在使用具有一个大型 RPC 服务的 GWT 应用程序。它有 100 多种方法，所有方法都做不同的事情。如果我将其拆分为多个 RPC 服务，我会获得什么样的性能优势/障碍？我相信我必须为每个人制作一个新的 servlet。
所以我的主要问题是： GWT 是否为每个正在运行的客户端创建一个新的 RPC servlet？ 如果我有两个 RPC 服务，GWT 会为一个应用程序提供两个 servlet 吗？ 拥有两个 RPC 服务会导致任何性能问题。目前（一个 tomcat 实例上有 10-15 个并发用户）
【问题讨论】：
标签： java gwt tomcat servlets rpc
如果我将其拆分为多个 RPC 服务，我会获得什么样的性能优势/障碍？
我相信这不会改变任何事情。
我相信我必须为每个 servlet 创建一个新的 servlet。
不一定。您可以有一个 RemoteServiceServlet 实现多个 RemoteService 接口。您必须在所有接口上设置相同的 @RemoteServiceRelativePath 以使客户端使用相同的 URL，但您也可以将相同的 servlet 映射到几个不同的 URL（多个 servlet-mapping 具有相同的 servlet-name）。
GWT 是否为每个正在运行的客户端创建一个新的 RPC servlet？
GWT 不会创建新的 RPC servlet，如果您将 Web 应用程序托管在 Tomcat 中，那么 Tomcat odes 会创建 servlet 实例（通常每个类只有一个实例）。
【讨论】：
多个 RPC 接口的一个可能缺点：如果接口之间有许多共享模型对象，GWT 将为每个模型对象生成FieldSerializers - 这些将被正确共享。但是，为了确保每个 RPC 实例只引用它需要的序列化程序，每个服务代理都会创建一个 TypeSerializer。在 10 个服务每个使用 100 个模型对象的情况下，这将导致 10 个TypeSerializers，每个具有 100 个FieldSerializer 注册（每个序列化程序的三个组件 - 序列化、实例化、反序列化）。
我已经看到至少有一个应用程序在这些共享模型对象的重量下几乎增加了三倍 - 超过一百个 RPC 接口，以及它们之间共享的数千个可能的模型对象。并非每个接口都使用了每个模型，但足以造成这种损害。通过分别维护每个接口对并制作一个扩展每个其他接口的巨型对来缓解这种情况 - 这样GWT.create 仅在该一种类型上调用，因此只创建一个巨型TypeSerializer 而不是数百个。
因此，请注意编译后的输出大小，并不时查看 SOYC（编译的故事）报告，看看是什么占用了所有空间。
【讨论】：