如果我处于这种情况，我有兴趣了解适配器调用如何从Worklight服务器的角度运行：
基本上，我们正在为必须使用通用功能的多个（ n ）适配器定义架构。 我们计划创建一个专用适配器来执行此操作，因此这样每个适配器都应该能够使用WL.Server.invokeProcedure API调用此“常用”过程。
令人怀疑的是，如果来自这几个 n 适配器的大量（ y ）请求调用此“常见”，则可能会在Worklight Server上出现性能问题在单个程序上接收大量调用。
我理解（或者至少有官方确认）是：如果Worklight服务器在适配器的单个过程（特别是HTTP适配器）上接收大量调用，那么如何管理这些调用（例如WL服务器管理）每次调用时并行调用不同线程的不同调用，或者将它们放在队列中？）如果使用另一个适配器在不同适配器之间共享过程是一种常见的做法（如果我们可以使用另一种方法来避免对WL服务器的额外调用） ）。
我已阅读了性能和可伸缩性文档，但我没有注意到有关此特定点的信息。
答案 0 :(得分：3)
您在适配器的性能设置方面可能感兴趣的一个方面是 maxConcurrentConnectionsPerNode。
maxConcurrentConnectionsPerNode – The maximum number of concurrent requests that can be
performed on the back-end application from the Worklight server node. This
maxConcurrentConnectionsPerNode parameter is set in the adapter.xml in the connectivity
entry.
There are two considerations when setting this parameter:
If there is no limitation in the back-end about the incoming connections then,
a "Rough" rule of thumb will be to set the number of connection threads per adapter
to be the number of http threads in the application server. A more precise rule
of thumb will be to understand the percent of requests going to each back-end and
set the number respectively.
The back-end may have a limitation on the incoming connection threads: In that case
we can have only BACKEND_MAX_CONNECTIONS/NUM_OF_CLUSTER_NODES connection threads where
BACKEND_MAX_CONNECTIONS is the maximum incoming connections define in the back-end
server and NUM_OF_CLUSTER_NODES is the number Worklight server nodes in the cluster.
您还可以查看Tuning Worklight Server文档，其中包含您在上面提到的一些方面：
https://www.ibm.com/developerworks/community/blogs/worklight/entry/tuning_worklight_server?lang=en