>OK, setting threads up higher isn't usually a smart thing. Hi Trey,
Up to about 3 weeks ago I would have agreed with you, and we had our limit for Simiultaneous Running Requests (let's call it SRR) set to 20. As part of a whole load of experiments to see what made a difference I played around with the SRR figure (partly triggered by something I'd seen on the web that a low number for SRR actually was unkind to the core Java engine of cfmx and caused the whole thing to run more slowly). I tried various numbers between 20 and 150 at that time, before settling on 96. Since then I've had several people telling me that it's a bad idea, but I have to say that it's far better than 20 *for us*. First - it normally doesn't come into play. 99% of the time we run fine, with an actual max SRR of maybe 15 at the outside. Normally it's 5 - 10. Over the last 100 secs we've averaged 5.11 page hits / sec, but running requests has averaged 5.0. That's normal. At 'normal' peak loads we get 8 page hits / sec and running requests may average 7 or 8. Second - I am absolutely convinced (and have been since CF 4) that if you ever start getting requests queued then CF runs more slowly and uses up more cpu. The key for me in managing this website on a day-to-day fire fighting basis is to avoid queuing at all costs. That's why 96 beats 20 hands down. If we used to have 20 times a day when we got overloaded and cfmx started queuing (and believe me it's been worse than that) when we had SRR set to 20, since I raised it to 96 we have 2 or 3. The other 17 are still there, but the running requests grows and then declines again before we get to queuing. Third - when we get overloaded we have lots of threads sitting doing nothing for several seconds (if they were running normally we wouldn't get overloads). The main effect of increasing the SRR is in queue avoidance, not splitting the available resources 96 ways. I cannot substantiate this because it is impossible to measure, but my gut feel of day after day experience is that an SRR of 96 will recover from the same overload much quicker than an SRR of 20. Say that at it's worst we had 70 threads. With an SRR of 20 that's 20 running and 50 queued. With an SRR of 96 they are all running. I've said, and I'm serious, that when it's queuing the cpu load goes up - way out of proportion - sql responses slow down (why?) and that's why I'm convinced that it recovers much more quickly if I can avoid queuing in the first place. My hiking the number to 200 is on the same quest. If people think 200 is silly, I'll go with that, but I won't drop it below 96. Contrary to what you suggest (and what I would have agreed with until 3 weeks ago) having an SRR of 96 makes the site run better, not worse. Whatever else I try as a result of discussion on this thread I won't be dropping that back to 20 because I know from experience that I'll be able to cope with much less load. Alan > >In general, use this formula for setting threads. > >Maximum simultaneous threads: > >For XEON's or other Advanced Processors (sun) >(CPU1 Mghz + CPU2 Mghz + CPU2 Mghz, etc,etc)/100 = Total MAX simultaneous > >FOR p2/p3/p4/amd/standard class cpus: >(CPU1 Mghz + CPU2 Mghz + CPU2 Mghz, etc,etc)/200 = Total MAX simultaneous > >Most of our production servers are currently dual 1ghz xeons. So 2ghz >total cpu availability / 100 = 20 Sessions total. > >This is a rule of thumb I have used for many years with great success. But >like I've said these are MAX settings, I usually set a little lower. > >Think about what your asking this to do. These are SIMULTANEOUS processing >threads, how many sections do you want to divide your CPU and system bus >into to complete requests? > >In general you will find more performance by throwing more processing power >at fewer threads as they will execute MUCH faster. Any requests over the >thread count are simple queued as they wait for CPU. > >Throwing ridiculous thread numbers into the config is only going to >partition your cpu out to the point individual threads only have 10-50 mhz >to run JIT compile and process the p-code. BAD!!! This will create what >appears to be stuck threads, threads that time out because of the maximum >processing time has been reached, etc. > >And in a windows environment, how much do you trust M$ to handle that much >multitasking ;). > >$0.02 > >Trey Rouse >Data Application Architect >Web Services - Rice University > > > >> -----Original Message----- >> From: Stacy Young [mailto:[EMAIL PROTECTED] >> Sent: Monday, August 11, 2003 12:43 PM >> To: CF-Talk >> Subject: RE: CFMX performance issue >> >> Simultaneous threads in the CF admin is set to 400 !? >> >> The traffic on our CF servers is not as high as yours, although peak >> hours are close, and we've only got ours set to 10 simultaneous >> requests. The highest we've ever gone is 12. When we had CF5 we once >> tried 18 but had some unusual problems. I'm not sure if "more is >> better". Have you tried a lower setting? >> >> As for the template cache, I doubt that would have a significant impact >> but I usually set it to a few MB's...since it'll only take what's needed >> anyhow. >> >> Stace >> >> -----Original Message----- >> From: Alan Ford [mailto:[EMAIL PROTECTED] >> Sent: Monday, August 11, 2003 1:18 PM >> To: CF-Talk >> Subject: CFMX performance issue >> >> I've raised the size of the template cache to 400 and raised the running >> thread count to 200 (from 200 and 96 respectively). Today we had several >> serious overloads at peak time (22k hits / hour, 500 connections). >> >> Alan >> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
