We are encountering some performance issues with the IS.
Our request to invoke a flow service typically takes around 1-2 secs to run. It is invoked via Java API by first creating the context and then do a connection to the IS, before invoking the flow service.
However, we have noticed that if there are already many sessions in the IS (around >10), our request takes > 10 secs to complete.
We have done some timing logs, and noted that the creation time of the context is roughly the same, but the context.connect(server,uid,pwd) will be slowed down considerably, if there are a number of sessions already present in the IS.
Basically if under low load (i.e. low number of sessions), it will work normally, but under high load, the requests take too long to complete.
Is there any way to tune the performance of the IS and/or packages, in the presence of high session count?
We have tried to increase the Java Heap Size to 1GB and up the max thread pool size to 400, but to no avail.
Configure the service(s) being called to be stateless. The session will then be automatically destroyed after the service exits. Generally speaking, top-level services should be configured as stateless unless there is a reason to do otherwise. Another approach is to have the Java code explicitly destroy the session.
Also, reduced the default session timeout if possible. 10 minutes seems to be a typical setting.
We have changed our top-level flow service from Stateful to Stateless. It seems to be working i.e. the performance is much more consistent.
Can I check if our top-level flow service calls another flow service, does the secondary flow service need to be changed to Stateless as well?
Or is it okay to just change the top-level service to Stateless?
Because our java client access the IS flow service by using context create, connect and disconnect very frequently (around 300,000 times a day), we are looking into reusing the session by not disconnecting it explicitly (i.e. wait till it expires).
We are hoping that there will be a significant amount of time saved (on the creation of the context and connecting to the IS), but we need to know if there are any pros or cons in doing so?
Only the top-level service needs to be configured as stateless.
If you want to keep the session alive then the Java code will need to explicitly keep and reuse the session. I’m not sure exactly what this entails but it shouldn’t be difficult. The code will need to handle when the session has timed out on the server side.