Ah! No Linux experience explains where your perspective is coming from. Unlike proprietary systems like Windows and Solaris, there is basically nothing you can't change on a Linux system. You can literally, rewrite whole sections of the kernel to tune your system if you like. In fact, the case study that Allaire did on my Linux CF 4.5.1 installation at TeamToolz showed some pretty high numbers for the time. These numbers were obtained by tuning the hell out of the machines including changing the source code to parts of the kernel.
I did talk with Jessie Knoller about writing a Linux performance tuning white paper. I even sent him a draft of it. However, I never saw anything come of it. I white paper is really needed for Linux and I would be happy to work with anyone who would like to have one written. Providing the data as a list here most likely won't work as there is an enormous amount of variables for tuning Linux. For example, I could give a list of file system variables that are tunable, but that list would depend on which file system you use. -Matt > -----Original Message----- > From: Dave Watts [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 24, 2002 4:12 PM > To: CF-Talk > Subject: RE: CF5 and SMP Performance... > > > 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 > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm 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
