> I think your methodology is sound if a single variable is in > isolation.
I think I at least mentioned other cases: "The problem with this methodology that I haven't addressed is cases of interdependent values, which is the place where expertise is necessary, but the vast majority of cases don't fall into that category." > The variable "Simultaneous requests" is not in isolation > however. There are plenty of other tunable variables that > can affect what value is best for simultaneous requests. > The only way to properly tune a system and application is > understand how each variable can affect the others. There > are simply too many permutations to test every possible > variable. Thus you need someone who understands the OS as > well as someone who understands the application. Since what > is tunable varies greatly between OSs, the methodology taken > is in fact different between OSs. I realize that it's not in isolation. If it were truly in complete isolation, we should be able to identify a tuning algorithm, and wouldn't require the general pain and suffering of the load test process. However, being affected by everything is essentially identical, for our purposes, to being affected by nothing - you simply can't know enough to do anything useful by looking at the things that affect it. Also, it's worth noting that for most OSs, there are a set of accepted best practices for base server configuration, and those practices don't change that much between one CGI database front-end and another. Let me preface this part with the statement that my Linux CF experience is near zero. However, I've done quite a bit of load testing and general performance tuning on both Windows and Solaris. I've not yet been able to identify a clear set of interrelated values, in which if I changed one it would affect the optimal number of simultaneous requests (assuming that we've determined an "optimal" value based on the current state of all other tunable variables) in one direction, but if I changed another it would push the optimal value in the other direction. I would argue that, in the case of the optimal value for the number of simultaneous requests, there are so many variables that it's pointless to examine them as a group. What I mean by that is, let's say you have a server, and you want to tune that server. First, you're going to apply whatever set of best practices there are at the OS and network stack level, and at the web server level. There may be some variances there depending on how you're going to use the server, the amount of traffic you expect the server to handle, the rate of that traffic, and so on, but most of the time, these variances are pretty small. Then, you've got a specific application or set of applications. Those may do various things, and they need to be optimized themselves, so you load test them to find the bottlenecks, and you fix the bottlenecks. In my experience, it doesn't matter whether you've tuned the previous layers or not, you're going to find the same set of bottlenecks in the same places within the application - the only thing different will be the severity of those bottlenecks. OK, so you find the bottlenecks, you change those portions of the application (assuming those bottlenecks aren't severe enough to require significant restructuring of the application, which may or may not be an option), you retest, you get acceptable performance. Then, you put the CF server through the same process - the biggest variance in the simultaneous requests setting in my experience has been that introduced by the application code itself - and you repeat the process. Again, in my experience, it hasn't happened yet that I've had to reexamine underlying layers in light of the simultaneous requests setting. Maybe things are significantly different on Linux; I simply don't know that. Maybe I'm missing some "big picture" thing that would allow me to provide a noticeable increase in response time and/or throughput if I only knew to set one thing to this value AND another thing to that value. So, if you can provide a list of specific items that should be examined, on a per-platform basis, when attempting to determine the optimal value for the simultaneous requests setting, or any other CF server setting for that matter, I - and the entire CF-using world - would be indebted to you forever. > I'll never pass up a good debate. It is the only way to learn! On the contrary. I've found that beating my head against solid objects in frustration also works. That's part of the load-testing methodology, you know. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
