...
| Info |
|---|
Adjusting the Worker CountEach worker creates its own connection to the JMS provider. Whenever a proxy is deployed/redeployed with a worker count that is higher than the default value of 1, you should see messages like "Started x listener(s)" in the Console (where x is the number of workers configured). Increasing the worker count can help performance under concurrency. The entire message processing chain of the proxy is parallelized, so each worker thread will do message correlations, response message generation, etc. in parallel with other threads. However, beware that if you provide a high worker count, deploying/undeploying/redeploying a proxy will take longer because there are more connections to create/destroy. Also, it is possible that the JMS provider has a limit on how many concurrent connections to allow. You should not exceed what is configured/allowed by your infrastructure. The worker count feature is equivalent to the “maxThreads” attribute in Tomcat server.xml; see Configuring SSL (HTTPS) for the Virtualize Server for details on where to find the server.xml for Virtualize’s Tomcat. When subjecting Virtualize to a high number of concurrent virtual users (i.e. during a load test), you can usually expect better performance by increasing these values. |
...
Global JMS settings that apply across a specific Virtualize server can be defined at the server level, then referenced here. See Connections Tab for details.
To use a global JMS connection, select it from the appropriate Queue or Topic box.
To review the details of a predefined global connection, click View settings.
...