> 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
