All Things WebSphere

Concerns and issues relating to all versions of WebSphere Application Server

Tuesday, December 20, 2011

Defensive queuing for website surge protection

Today's blog post explains a deployment and tuning methodology to protect your application server from a traffic surge.

In the figure below decreasing values are assigned to the tuning parameters for each of the displayed Web site components. This deliberate reduction in the maximum number of available resources assigned to each successive layer is called the Funnel model methodology. The benefit of the funnel tuning model is that we
want as many clients to connect to our system as possible, but without overwhelming the resources in each of the layers downstream (for example, database connections). The funnel helps us place these requests into various queues at each layer, where they will wait until the next layer has the capacity to process them. In summary, the funnel model helps us handle bursts of client

Queue tuning points in a Java EE Web site: the Funnel model

For some high level guidance and theory see. The proportion and ratios of the various queues to various another is very important in determining the queuing that occurs at load. If every incoming request requires a connection to a back-end database then the datasource connection pool should be at least equal in size to the servlet thread pool.

What is the size of the WebContainer threadpool in relation to the connection pool ?
What should be the IHS thread/process configuration in relation to the WebContainer threadpool ?

Answer from SWAT guru Kevin Grigorenko -->

The ideal proportion is 1:1 with all wait time on the network, but that assumes all layers perform and scale the same, which is rarely (if ever) the case, so only the general recommendation of 1:<=1 is made. Also, requests are not all the same, so one request may use more memory on a thread than others.
In general, I recommend customers "play it safe" -- for example, start at the max database concurrency, N, then set WAS WebContainer to 1.5N (could go more since a lot of times requests are just for static content) and then set IHS to 2N.
But a lot of stress testing is required at the boundary of the incoming queues -- the biggest problem is that customers configure the front queue (e.g. IHS) at N but then don't even create a test that sends N concurrent requests in. When that happens (spike in load, DOS attack, etc.), their JVMs or database crash/OOM.

Labels: defensive queuing

posted by Rohit Kelapure # 10:29 AM

Comments:

All Things WebSphere

Tuesday, December 20, 2011

Defensive queuing for website surge protection

Post a Comment

Archives