Simultaneous Requests in CFMX 7
Feb 7
posted by Steven Erat in
ColdFusion, Quality Assurance
| 5 Comments
Watch that setting! While ColdFusion MX 7 Server Configuration installs with a default value for Simultaneous Request at 8, the Multi-server configuration has a default setting of 25 for this parameter.
ColdFusion MX 7 has the same rule of thumb for starting values on this parameter, just 3 to 5 per CPU on the machine. The default Server Configuration setting falls into that range for a 2 CPU machine, but the Multiserver Configuration value of 25 Simultaneous Requests may be too high for your application.
This is one of the most important settings in ColdFusion MX server, and the best way to determine the optimal value is through good load testing during development or staging. By keeping all things the same and modulating just this setting up or down, you can plot a graph on throughput.
Most likely you would see a curve where too low a value unnecessilary limits what the server can handle, and too high a value causes excessive work to just manage so many web threads that not enough time is spent on just executing the threads. When plotting throughput on the Y axis and Simultaneous Requests on the X axis, the sweet spot would be somewhere in the middle of the throughput curve at its highest point.
Just keep any eye open for this setting when creating any new CFMX JRun server instances.
For more information on this topic, see my more recent blog entry:
activeHandlers or Simultaneous Requests: Less is More
#1 by cfmx on 2/7/05 - 4:43 PM
#2 by Steven Erat on 2/7/05 - 4:49 PM
The Microsoft Stress Test tool works well too as a pure sledgehammer, but isn`t sophisticated at all.
#3 by Calvin Ward on 2/8/05 - 7:37 AM
#4 by Steven Erat on 2/8/05 - 10:26 AM
The answer can vary depending on many factors including broad considerations of whether you own or are knowledgeable of all the applications to be running or whether you are an ISP.
The ISPs that I`ve worked with tend to grossly overload the server so that if any application decided to actually use half the memory it was allocated then the machine might be hosed for a while.
I think you`d want to apply the same principles when testing a multiserver config as when testing a single server config. Load testing is always the best answer, and even some load testing say with the MS tool is better than none. (Oh, and there`s OpenSTA as another interesting, free choice). If you think your app is more query-centric or somehow third-party-centric, then it will use the cpu less than those that are more logic and processing intensive. A query sensitive app can handle a wider throttle since the cpu has to work much less while threads are idly waiting for remote responses from a database (or perhaps a CFHTTP or Web Service call).
I think overall you`d want to make sure that there are ample resources available such that the CPU hardly ever works more than 70% and the total memory on the machine also isn`t past 70% on a regular basis. If the CPU is working less on average then you can probably throttle up, and if its working at a higher rate then you`re very close to getting into a thrashing death spiral. Use the system`s resources optimally, but leave room for bursts of higher requirements.
How`s that?
#5 by robi on 3/12/05 - 12:25 AM