Obviously, my applications have been tested under load. I just don't get paid to do elaborate server stress/heavy load testing. I suspect that many web developers don't.
I wasn't telling half a story. I wasn't advocating anything illegal or immoral. I was simply saying that the "Single Threaded Sessions" setting works and is a handy option to consider. In my twenty+ years of programming, I've noticed that technical people tend to fall into two camps -- those who admire simplicity and those who admire complexity. (I've also noticed that complexity pays better. ) You're obviously in the latter group. You've practically written a book here. If you were to charge me your hourly rate for all this, I'd have to take out a second mortgage. ----- Original Message ----- From: "Dave Watts" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Friday, June 14, 2002 11:20 AM Subject: RE: Application Slow Down was RE: Absolutely necessary to cflock session variables > > It's a mystery why you continually come down on me for > > recommending that people try the Single Threaded Sessions > > setting. > > I think you misunderstand my intent. I continually come down on you for > neglecting to mention that you haven't tested this under load. In my view, > you're telling half the story. You'll notice that my response didn't say > "Don't use this feature or you'll be sorry!" or anything along those lines, > just that it tends to cause severe performance degradation under load. > > > The developers at Allaire/Macromedia chose to design and > > implement this feature. It seems to work as documented. > > There are lots of things that are implemented in CF that, in general, are > bad to use from a scalability perspective, such as storage of Client > variables in the Registry, and support for MS Access. Those also work as > documented, but most people wouldn't recommend their general use without > noting potential issues with performance and scalability. Two things that I > find cause a lot of performance problems are overuse of custom tags and the > CF 5 query-a-query functionality. > > > Why can't I point it out to people and relate my experience? > > You can, and have. That's the beauty of free speech. I, on the other hand, > have the freedom to respond, in the hope that the "best" speech will > prevail. Of course, I have an opinion about which is "best", but that > doesn't mean I'm right. > > > Here's the statement I was responding to... > > > > "Keith, what I have found with this is a severe degradation in > > performance in any reasonable sized application when this (Single > > Threaded Sessions) is selected." > > > > In my experience, that is demonstrably false. Isn't my experience > > valid? > > Yes, of course your experience is valid. All we have in this environment is > experience - there's no a priori knowledge about server performance, and > common sense can often steer you wrong. However, just because Mike may have > made an overly vague statement doesn't mean that the appropriate response is > another overly vague statement in opposition. > > Further, if people are going to be in error over this, I'd prefer that they > err in favor of safety. It really, really sucks to tear apart an application > at the last minute to fix errors in the other direction. > > > And it *is* contrary to the documentation and to common sense. The > > documentation addresses the *nature* of the performance degradation > > and it clearly does not apply to "any reasonable sized application." > > That sort of exaggerated blanket statement is counter-productive and > > deserves to be questioned. > > Well, I'd agree that "any reasonable sized application" is pretty ambiguous. > I'd argue that it's not the size of the application, but the size of the > userbase that counts. However, I suspect that this is essentially what Mike > meant in the first place. > > > > Every time this topic comes up, you always state that you've never > > > seen any degradation in performance with single-threaded sessions, > > > and strongly recommend its use. > > > > Note the distortion you have introduced to my POV. I don't *strongly* > > recommend use of the setting. I strongly recommend taking dogmatic > > bluster with a grain of salt and deciding for oneself. > > I agree that "dogmatic bluster" isn't especially useful. However, if you're > going to combat dogma, you have to talk details. There's a reason I've > clearly stated that the issues with using this setting are related to > performance under load, and if that's not a problem for you, then there's > nothing wrong with using the setting. The reason I've gone to that trouble > is that things tend not to be black or white, but gray. > > As for the strength of your recommendation, well, every time this topic > comes up, you recommend its use without reservation. I interpret that as a > strong recommendation. A weak recommendation would be "you might try it, but > keep in mind that it won't scale well". > > > > I have seen significant performance degradation for applications > > > under load generated by load-test tools and by real users. > > > > > > In any case, if your applications aren't going to support the amount > > > of load that would be necessary to cause performance degradation > > > problems (and you're sure that they never will have to support that > > > amount of load), then ... > > > > Dave, we're not all in your lofty class. ColdFusion is a wonderful > > tool for small to medium sites and that's where I live. I suspect > > many people are in my situation. > > Yes, many people are in your situation, until they're in my situation. It's > not a matter of being "in [a] lofty class". The applications that I work > with are written by CF programmers all over the chart, skill-wise. The fact > that I'm involved, though, usually means there's a problem. There's a fine > line between not having to worry about performance, and having to worry > about it. I've encountered several cases in which an application that was > originally deployed for a small userbase got exposed to a much larger > userbase. Things often don't go well in those cases. > > While ColdFusion is a wonderful tool for small to medium sites (again, by > size, I really mean userbase), it's also a wonderful tool for large sites. > However, there's a common misconception that CF doesn't scale. It does - but > not all CF applications scale. > > > Server testing under extreme load is something I would do only on > > rare occasions, because my customers tend to pay me for real work. > > Trust me, it's real work. Personally, I think it's more work than > programming. And, of course, extreme load is a relative term - it simply > means for most people "more load than I ever expect to see". > > > In general, I make sure that the server is significantly over-powered > > for the application. Maybe that's not an approach you're inclined to > > consider. For me, buying hardware is a lot cheaper than paying high- > > priced consultants to come in and contemplate their navels. > > Perhaps so, but not everyone has the alternative to double their existing > hardware overnight to meet unexpected demand. Recently I encountered a > situation in which an application couldn't support the required load, and it > was running on a cluster of three multi-processor Solaris CF 5 servers. > Should I have just said "buy more servers"? Or should I have found and fixed > the problem(s)? I'm certain that it was cheaper for them to pay me a high > hourly rate for a day or so than it would have been to purchase and > integrate a couple more Solaris boxes. > > > > Of course, in that case, there are all kinds of corners you might > > > cut and not suffer for it. Applications can have many problems that > > > aren't apparent until they're run under load. If I had a dollar for > > > every time I ran into a problem like this, in which an application > > > that works fine during functionality testing fails under load - oh, > > > wait, I DO have a dollar for every time ... > > > > This is condescension. You see a link between use of the Single > > Threaded Sessions setting and incompetent programming. I'm sure you > > have lots of dollars but your point is irrelevant and insulting. > > It may be condescending and insulting (that wasn't my intent, and I don't > really think it is), but it's not irrelevant. The fact is, while you may be > safe for using this setting, and you may be absolutely sure you're safe - > and you may be absolutely right - someone else, reading your response, might > say "well, this guy isn't having any problems, so let's use that". I spend a > decent amount of time fixing problems like this. Maybe they're not your > problems, but that doesn't make them less real. > > This, specifically, is the reason why I felt it worth my time to respond to > this yet again. There are many features within CF, or any other programming > language, that are potentially dangerous when used incorrectly. It's a bad > idea, I think, to simply say "they work" when in many cases, they won't > provide the intended effect - a functional, satisfactory application that > can support its userbase with the amount of hardware that it has. While you > may use this feature successfully (which empirically may make you a > competent programmer), there's a difference between you and someone else who > might not know or understand the ramifications of this setting under load. > > Finally, while you don't like the implication that using the setting is > cutting corners, it most clearly is. For a while, MM has strongly > recommended that you simply lock each and every instance of memory variables > used in your application. Many people have focused on workarounds, rather > than actually just putting the damn CFLOCK tags in their code. We've tried > all these things ourselves, because like any other programmers, we're lazy > here at Fig Leaf and would prefer not to have to do all that typing. But, > the fact remains, workarounds are still workarounds. > > > > I heartily agree with your suggestion for people to try the > > > setting and decide for themselves. > > > ... > > > I'll agree that there are times when you may be better off > > > using this setting as opposed to writing locks throughout > > > your codebase > > > > I see the beginnings of a sea change. Pardon me while I take a > > moment to savor it... > > Well, first, if you're getting any enjoyment from that, you really need to > get out more. Second, there's no sea change - I'm not saying anything new. > I'm saying what I've always said - this feature doesn't work well under > load. No load, no problem. > > > Competent programmer writing clean, MX-ready code. > > .. MX-ready, but not CF 5-ready? Well, that's a bit unfair, I guess, but > how can I resist? > > In conclusion, I would think that a recommendation that will work in all > cases, though it might require more work from the programmer, is superior, > all other things being equal, to a recommendation that will only work in > certain circumstances, and that requires expertise to differentiate those > circumstances from others in which it won't work. To me, the first > recommendation would generate cleaner code - it may be more verbose, but it > doesn't impose limitations on its use. > > 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
