It's a mystery why you continually come down on me for recommending that people try the Single Threaded Sessions setting. The developers at Allaire/Macromedia chose to design and implement this feature. It seems to work as documented. Why can't I point it out to people and relate my experience?
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? 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. >> 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 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. Server testing under extreme load is something I would do only on rare occasions, because my customers tend to pay me for real work. 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. >> 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. >> 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... Keith Meade Competent programmer writing clean, MX-ready code. ----- Original Message ----- From: "Dave Watts" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Friday, June 14, 2002 12:57 AM Subject: RE: Application Slow Down was RE: Absolutly neccesary to cflock s ession variables > > > > If you have control of the CF server settings, consider > > > > enabling "Single Threaded Sessions" in the LOCKING section > > > > of the CF Administrator. Then you don't need to lock any > > > > session variable references. > > > > > > Keith, what I have found with this is a severe degradation > > > in performance in any reasonable sized application when this > > > is selected. Just my experience. > > > > That's contrary to my experience and to the CF documentation. > > I've seen virtually no degradation of performance. > > Hi again, Keith! +> > 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. I respond by saying that I have seen significant > performance degradation for applications under load generated by load-test > tools and by real users. So, here's my response, once again. > > > Here's what the CF (version 5 CFLOCK) documentation says > > about the Single Threaded Sessions setting... > > > > "This feature may have an effect on performance depending on > > the request pattern. For example, the total response time may > > increase if an application has multiple frames that can be > > refreshed at once, thus causing multiple requests to queue > > and wait to be processed." > > > > It wouldn't surprise me that there are some conditions under > > which you would *not* want to enable Single Threaded Sessions. > > More guidance from Macromedia would be helpful in this area. > > > > I highly recommend that people try the setting and decide for > > themselves. > > I heartily agree with your suggestion for people to try the setting and > decide for themselves. That's what load-test tools are for. Nevertheless, it > strikes me as kind of specious for you to state that you've seen no > degradation of performance without noting that you haven't tested the > setting under load, as you've stated in the past. Of course, if you've done > so since then, and you still didn't see any performance degradation, that > would be a different matter. But, I suspect that this isn't the case, since > every time I've done so, the server took a beating with that setting. > > Also, I think you're misreading the documentation, since you state that > Mike's anecdotal evidence conflicts with the documentation, while the > portion that you quote specifically mentions performance degradation. Why do > you think that the documentation mentions this as a potential problem? As > for more guidance from MM, well, they give you enough rope for you to hang > yourself - I'll agree that there are times when you may be better off using > this setting as opposed to writing locks throughout your codebase, but it's > up to the individual developer to perform his own cost-benefit calculus. > > 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 > there's nothing wrong with using the setting. 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, never mind. Too many developers > learn the hard way that something which seems perfectly acceptable during > development may fail catastrophically when the server is pushed to its limit > - and far too often, they learn this with real users. > > Finally, this may become a moot point once CF MX is widely adopted. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > voice: (202) 797-5496 > fax: (202) 797-5444 > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.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
