> I've never seen you issue such an insulting reply. You > yourself have stated that you have no "real" information > to back up your claims. > > Sorry that I disagree with you, but I don't care to have > my professionalism questioned.
I'm sorry that you read my response as a personal insult. However, I stand by my statements. If you find that they apply to you in a negative way, so be it. I think that my underlying point is valid, and important enough to pursue, and state repeatedly if necessary. If you find yourself to be in that last category: "Now, if you write code which you know will always be under your direct control, and you know that you can configure the server any way you like, and you know that the code won't have to support significant number of users, then there's nothing wrong with omitting your locks and using that setting." then you have nothing to worry about, right? However, if I say "everyone not in that category should do otherwise", how does that affect (or insult) you? I've also stated that there's very little "real" information - algorithms, or recipes that you can feed inputs into and get outputs - to demonstrate any performance tuning best practices - and yet, these best practices do exist. Where do they come from? The experience of developers, who try a thing; if it fails consistently, then they take that into account. As an example, for a very long time, there's been a setting in the CF Administrator labeled "Number of simultaneous requests". For nearly as long, many developers (both Allaire/MM and external ones) had various algorithms for determining the optimal result, such as "multiply the number of processors in your server by five". Well, guess what - there IS no algorithm for finding the optimal result! You have to perform load tests, with your server configuration and with your applications, to find out the optimal value - and it can make a significant difference in performance. Now, I don't have any "real" information as to what that setting should be - but I can make a valid determination, given a server environment, a set of apps, and a copy of OpenSTA or Segue SilkPerformer. That's how you find out answers to questions like these. It's not like everything's listed in some "Big Book of Server Performance Answers" - there are often simply too many variables in the mix. Now, given that, if I say that, in my experience, the single-threaded session setting causes performance problems, how do you think I came to that conclusion? But, the beauty of this is that you don't have to believe me. Find out for yourself. Download OpenSTA (http://www.opensta.org/), learn how to use it, set up a testing area which models your real environment, set up your apps in that environment, and run two sets of tests: one against your current app, without CFLOCKS and with that setting enabled, and another against a modified copy of your app with CFLOCKS and without the setting enabled. > Shame on you. Again, I'm sorry that you're taking this as a personal insult, but I'll not feel shame for expressing my opinion, based on my experience, that this approach is, all other things being equal, bad. Bad, bad, bad. Not good. Suboptimal. Best avoided. Not recommended. Have a nice day! 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/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
