Worklight Adapter performance

Question

I'm interested in understand how the Adapter invocations works from Worklight server point of view if I am in this situation:

Basically, we are defining an architecture for several (n) adapters that must use a common function. We are planning to create a dedicated adapter to do this, so in this way each adapter should be able to call this "common" procedure using WL.Server.invokeProcedure API.

The doubt is if with a large number (y) of requests from these several n adapters that call this "common" one may occur performance issues on the Worklight Server that receives a lot of invocations on a single procedure.

What I would understand (or at least have an official confirmation) is: if the Worklight server receives a lot of invocation on a single procedure of an adapter (particularly, an HTTP adapter) how manages these invocations (e.g. WL Server manage different invocations with different threads in parallel for each invocation, or put them in a queue?) and if sharing a procedure between different adapters using another adapter is a common practice (and if we can use an alternative way avoiding an additional invocation to WL server ).

I've read the Performance and Scalability documents, but I haven't noticed information on this specific point.

Answer 1

One aspect that may be of interest to you in regards to performance settings of adapters is 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.

You can also look into the Tuning Worklight Server documentation that covers some of the aspects you mentioned above:

https://www.ibm.com/developerworks/community/blogs/worklight/entry/tuning_worklight_server?lang=en