WebLogic 8.1/Grinder Load Test - Execute Queue ThreadCount vs. max-beans-in-free-pool and max-beans-in-cache
Study Objectives
This study shows the relationship of Execute Queue ThreadCount and max-beans-in-free-pool and max-beans-in-cache
configuraton parameters.
These tests used values of 10, 15, and 20 for both max-bean- parameters to measure their effect on Success and Error transactions where workload threads were varied over a range of 5 to 40 and Execute Queue ThreadCount from 5 to 25.
The bean managed banking application used 10 account beans per client. A separate machine hosted a MySQL server.
JDBC Connection Pool MaxCapacity was set at 30 beans.
Test Results
Four performance statistics, Test per Second (TPS), Response Time (Mean Time), number of Successful Tests and number of Errors, are compared graphically across the range of workload threads labeled X1:Grinder_Threads on the x-axis.
For max-beans-in-cache and max-beans-in-free-pool set at 15, this chart shows that errors begin to occur at 20 workload threads for Execute Queue ThreadCount at 15 and above. At an Execute Queue ThreadCount of 25, there are hundreds of errors, which causes the superimposed TPS and Successful Tests curves to drop off increasingly from 25 workload threads and higher.
Stepping through the Execute Queue ThreadCount settings
The Java 1.7 Plug-In Applet Viewer is configured to plot Grinder TPS, Mean Time, Successful Tests and Errors over the tested range of Grinder workload threads. JDBC Connection Pool MaxCapacity is set at 30 beans.
Execute Queue ThreadCount is pre-selected as a secondary X-axis variable and varies over its complete range producing a family of curves.
To manually cause the values of the performance statistics to change with increasing Execute Queue ThreadCount,
use the viewer controls in the left pane as follows:
Un-check Animate. (This checkbox is not available with the non-JFreeChart version of the applet).
Un-Check AutoScale. This freezes the Y axis scaling so that curves will move up and down within the frame with changing performance.
Select the X2 radio button and click on the highlighted Input Parameter label, "X2: weblogic.kernel.Default_ThreadCount" to toggle off its selection as a secondary X-axis variable.
Select the X2+/- radio button. This mode allows non-selected Input Parameter values to be changed.
You are ready to scan through Execute Queue ThreadCount settings, so take note of the first set of performance curves for Execute Queue ThreadCount set at 5.
Click the primary (Left?) mouse button once over the same Input Parameter label as in step 3, which is now labeled "weblogic.kernel.Default_ThreadCount:5" to change the Execute Queue ThreadCount from 5 to 10.
Notice in the new sets of TPS and Mean Time curves that performance improved and that no significant Errors were introduced at all workload thread levels.
To see this change again, toggle Execute Queue threadCount levels back and forth by alternately clicking the right and left mouse buttons on the weblogic.kernel.Default_ThreadCount label, ending with a Execute Queue ThreadCount of 10.
Click the primary mouse button TWICE again over the same weblogic.kernel.Default_ThreadCount label
to change from 10 to 15 to 20 threads. Notice that TPS and Mean Time performance improves again, but now
there are around 75 Errors at the 30, 35 and 40 workload thread levels.
Repeat once more to increase Execute Queue ThreadCount to 25 threads and notice that Errors have jumped to
250 at the 40 workload threads level, which has caused the TPS performance to drop in this range of the high error rates.