>It also sounds as if youre approaching the limit of this configuration.
Well, I agree with that, but my point is that we shouldn't be. We have one of these dual Xeon processors with hyper threading that makes it look and act like a quad processor. It has 1gb of ram and is using 625mb. The only time it has a slight problem with the load is if one of the legacy servers takes longer to respond than usual - we then see the running thread count grow, but it grows predictably and it grows understandably. The app is scaling well. Our response times do vary, but not in line with the load. They vary with how well the legacy servers are responding. The number of bytes transmitted obviously varies in almost direct proportion to the load (hits / sec), but we've had a response average of 403ms on a load of 5.9 hits / sec, and a resp average of 397 on a hit rate of 7.2 hits / sec (this averaged over 100 secs). We never get much below 300ms even in the middle of the night. Cpu load is about 40% when we are running hard. What is limiting the site is not load, nor lack of performance, but something that looks for all the world like a cfmx bug (yes, I know performance issues are almost always app related - but what control do I have in the app over how cfmx handles the thread cache. Why, when I took the thread dump, were some 60 threads waiting on the template cache?). At peak loads we're getting about 8 hits / sec. Assume each module called is well written and uses include files, custom tags, UDF's and cfc's to do it's job. Say each module uses 20 of those (probably an over the top estimate). Even with our cache set to 200 modules almost all would have been in the cache (we have 313 class files, but many of these are used only rarely). So it needs to do 160 cache reads / sec. With the processor power we have that sort of load should be way less than trivial. Even at 1ms each to retrieve them from cache, what's it doing for the rest of the time that gets it into an overload? Without this overloading problem we'd be running quite happily and taking all the load people could throw at us. >6.1 is an obvious answer. I've noted speed and stability improvements. We're going for it. >you probably want some stopgap solution that is low risk to give you >some time to test and perform the upgrade to a cluster or more powerful >machine or something. We're going to a load balanced dual server solution with clustercats and each server will be more powerful than the one we are using. We're also upping our bandwidth. >I would recommend adding ram and uping your thread count. We have about 300 - 400 mb of unused ram as it is. I thought a thread count of 96 was quite high. What is the recommendation these days (aren't MM still saying 4 x number of processors)? But again, that will only do what I've already done - make it slightly more difficult to get into an overload situation. Without anybody addressing what appears to be the basic problem then raising the thread count is only tinkering, going to 6.1 is only tinkering. Underneath the hood this problem is still lurking and will happen again (and will happen to others). >Another thought is to perhaps leverage the java under the hood to speed the >file writing activity. I did wonder whether that was possible. After literally years of trying I've finally managed to persuade them to rewrite the interface to these legacy systems - we'll shortly be using a web service instead, so I'll probably leave the file io as it is. >Always better to be swamped than bored!!! > >Good luck! Quite right, and thanks! 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 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 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
