>I agree that your number of simultaneous threads is really high. I >think that Ben Forta once recommended only 3 threads per CPU. That >seems a little low for me. > >I would lower the threads to a reasonable level
See my reply to Trey - I don't want to lower the SRR below 96 as I know it will make my problems worse, honest. > and also lower the >timeout requests (in server settings) to something low (maybe 20s or >lower). I have a problem with this in that if the legacy servers don't respond we want a controlled timeout rather than a timeout error. So we allow them 30 secs (by which time they spot that they've timed out and tell the user nicely) and then timeout threads after 32 secs. I'll have to change the legacy handlers to use requesttimeout = 30 before I can drop the timeout figure, but I must admit that I have been thinking of doing that. Our long running threads can be literally anything. We have a fairly simple homepage that takes about 200ms to deliver (on a bad day), yet we've had that timing out. But most of the pages timing out are ones that are allowed to take a long time because sometimes they legitimately do. A legacy response of 15 secs is far from uncommon and perfectly valid. They also happen to be our busiest pages (most often hit). We have to live with slow page responses, as you'll understand from the above. But we have to live with those day in, day out. If one of the legacy servers is in a bad mood I can see the effects that has on other threads, cf and the site in general. If we are waiting for replies we are doing a series of java sleeps - using minimal resources - and the effect on the site is not significant. We just have a few threads tied up. >I truly think that your problem lies in cflocks. I have had a lot of >trouble with >"named" locks as opposed to "scope" locks in CFMX We certainly have plenty of those. But I can't change the file system locks to session scope, because that doesn't lock things enough, and I can't use app scope locks as that is locking too much. I can't see how I can change them to scoped. We have had some very strange problems with the file accesses. The reply file is written by the legacy server across the network. If we read and delete it in one lock the delete often fails with 'somthing else already has the file open', so we have to have a sleep (or a few sleeps) before it will delete. We also had 'cffile attribute is invalid - filename' when we'd just used the exact same filename in an earlier action. These disappeared, but I didn't fix the problem (if you know what I mean). I am really looking forward to getting rid of the file interface as it's not something cfmx is good at. 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
