How to measure the Webmethods IS whether it can handle 100K web service session in one time?

Dear webMethods Gurus,

We are going to conduct stress test on our environment.
Our webMethods is IS 9.5 with latest fix.
There will be 100K session in one time accessing our web service which hosted in our webMethods IS which in cluster.
We have two IS server as a backend to handle these requests.

Our question is how do we know if our webMethods servers are capable on handling this such request?
I heard we need to fine tune the thread in IS but i am not sure how.

I already asked WM Support, it said this is not part our their support to answer.

Kindly advise.

Best Regards,
Fanny T

Hi Fanny,

under Settings → Resources you will find settings for minimum threads and maximum threads.

Please have a look at the IS Administrators Guide and the Clustering Guide for further informations.

Additionally make sure that you have increased your maximum jvm memory in the IntegrationServer/bin/setenv.sh to avoid OutOfMemory issues.

Regards,
Holger

Hi Holger,

Thanks for the advise.

Could you advise what is the best practice on setting up the minimum and maximum threads?

Currently our servers is having the maximum threads set to 2000.
And our JVM memory has been set to 4GB.
And we have 2 servers in cluster, so i guest both of them can handle until 4000 threads in a time.

Do you think our server can handle that such request? (100K webservice request)

Kindly advise again.

Danke,
Fanny T

Additional question:

  1. what is the maximum thread that we could specify? Is it depends on the server memory?
  2. Is there a resource to thread ratio we can use?
  3. Is it true that application max thread are meant to control asynchronous threads not synchronous?

Appreciate your help.

Thank you.

Best Regards,
Fanny T

Hi Fanny,

these values are kind of experimental.

Each thread requires a certain amount of memory in the JVM.

You should monitor the server.log for “Available Threads”-Threshhold warnings.

Regards,
Holger

Hi Holger,

Actually the requirement is our server need to be able to handle 12K webservice request within 90 sec.

So i did some rough calculation thread to use.

Based on my observation, 1 web service request will be served in 1 session and it took 4 sec to completed.
And i assume, 1 IS service is using 1 thread, so 1 webservice is using in average 10 IS services.
Let say if we want to achieve all 12K request in 80 sec.
In 80 sec there will be only 20 web service requests are served. If we divide the 12K with 20 then we will know that we need 600 more request and since 1 request requires 10 thread, so we need about 6000 thread in total.
So we need to configure max thread into 3000 for each server.
And just to be safe we can set may be 4000 each.

Let’s assume each thread will consume 100KB memory, so 12K web service requests will consume about 3000 x 100KB = 300MB JVM memory.
And since we configure the JVM Max is 4GB, i think it is still can handle the request.

Any comment? please welcome.

Thank you.

Best Regards,
Fanny T

Basically you need to test this. Imho you will need a cluster and should have more than the minimal amount of node, so of a node goes down the remaining nodes can still handle the load (If availability i part of your requirements).
How many servers are enough depends on the complexity of your services. On Empower there are techreports available giving the performance of Software Ag products and for IS you will find how many services can be invoked on a specific hardware. But this too won’t spare you your own performance tests.

based on my experience, each session will need much more than 100K of memory. It also depends on what your WS do, how fast it can do it.
Do some tests with a testing client tool.
Start with 100 concurrent sessions, you will get the idea how much memory/CPU you will need for achieving this.

Hi All,

Many thanks for the valuable input.
We have tested with our trading partner about 12K web service transaction and we came to conclusion that our server is good enough to handle the request.

Thank you again.