Then of course there is Moore's law, which often makes tuning a waste of time. In fact, I think we are basically there for web serving. See my editorial on Evolt.org, http://www.evolt.org/article/Scalability_s_New_Meaning/21/23896/index.ht ml.
-Matt > -----Original Message----- > From: Jesse Noller [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 25, 2002 7:54 AM > To: CF-Talk > Subject: RE: CF5 and SMP Performance... Linux > > Ah, let me throw in the towel here. > > Yes, I talked with matt here about a paper, in fact, I have several > THOUSAND pages of information on this very subject stacked in a box on my > bedroom floor. > > I spent months going over it. > > Then redhat 7.2 came out, and invalidated it ALL. > > Yes, there are whitepapers needed, and I encourage the community to > create these. However, as most of my time has been eaten by the great "new > release beast" there is going to be some lag time before I can start > writing the articles again. > > Meanwhile, the tips that will actually help you across > distributions, and revisions of Linux (As everytime the vendors release, > they invalidate the wealth of knowledge we had): > > 1: Recompile your kernel to be uber light. Remove anything > unnessecary. > 3: Same goes for apache. > 4: Have lots of ram. > 5: make sure you're running at least a 2.4 kernel. > > That's it. Yeah, I could write a book on what we know for tuning > parameters, and hacking a linux box (or solaris machine) for optimal > performance, but it all boils down to a limit of time, and the fact that > most of the information is negated the minute we release. > > Back to my hole now. > > -jesse noller > > > -----Original Message----- > > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 24, 2002 7:19 PM > > To: CF-Talk > > Subject: RE: CF5 and SMP Performance... > > > > > > 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 > > > > > > > > > ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. 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
