Worklight 适配器性能答案

【问题标题】：Worklight Adapter performanceWorklight 适配器性能
【发布时间】：2014-03-27 14:30:26
【问题描述】：

如果我处于这种情况，我有兴趣从 Worklight 服务器的角度了解适配器调用的工作原理：

基本上，我们正在为多个 (n) 必须使用通用功能的适配器定义架构。我们计划创建一个专用适配器来执行此操作，因此每个适配器都应该能够使用 WL.Server.invokeProcedure API 调用这个“通用”过程。

问题在于，如果来自这几个 n 适配器的大量 (y) 请求（称为“常见”）可能会在 Worklight Server 上出现性能问题在单个过程中接收大量调用。

我会理解（或至少有官方确认）是：如果 Worklight 服务器在适配器（特别是 HTTP 适配器）的单个过程上接收到大量调用，如何管理这些调用（例如 WL 服务器管理每次调用并行使用不同线程的不同调用，还是将它们放入队列中？）以及是否使用另一个适配器在不同适配器之间共享过程是一种常见做法（如果我们可以使用另一种方法来避免对 WL 服务器的额外调用)。

我已经阅读了性能和可扩展性文档，但我没有注意到关于这一点的信息。

【问题讨论】：

标签： ibm-mobilefirst worklight-adapters worklight-server

【解决方案1】：

您可能对适配器的性能设置感兴趣的一个方面是 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

【讨论】：