Life is always surprising, ColdFusion as well. If one talks about finding the best or just a good value for the simulatenous requests setting in your ColdFusion server, the recommended approach is to start with a value of 3 to 5 per CPU.
Usually this works pretty good, maybe you have to adjust the values to 6 or 8 or even 2, but this time it was a bit different. I spent the last two days to deliver an ColdFusion administration and tuning training at one of my clients and during those two days we started setting up a ColdFusion custer infrastructure for them.Firstly: the mentioned values of 3 to 5 per CPU are just to start with. It is strongly recommended to do load testing with the application to figure out what the best setting is.
Let me explain what happened: They run a huge data warehouse database – and I really mean huge – connected to several ColdFusion applications. The final big queries of the data warehouse database itself might take up to several seconds to return a recordset. The machines have 2 to 4 CPUs, so we started with the default setting of 8 simulaneous requests and put some load onto the applications.
We simulated amount from 10 to 50 users clicking around once per 10 secs in average. An interesting observation was the the requests queued up as hell – well, makes sense if you consider that the database queries and connection(s) do most of the work. And if you just allow 8 sim. requests… a lot of requests had to wait for others to finish.
With that we increased the value for simultaneous requests and finally found it to be very good on 40 for a 4 CPU machine (which breaks down to 10 per CPU) and 25 for a 2 CPU machine (12.5 per CPU) – after different sets of load and stress tests.
Both settings are quite far above the inofficial-official 🙂 recommendation but the explanation is quite simple: The recommendation is for typical ColdFusion apps which have to do some “real” work in CF besides just being a boiler for DB queries. So, if there’s not much work to do for the ColdFusion request, it doesn’t take that much CPU power and workload in general. This means that there’s no reason not to allow an increased value of simultaneous requests than the recommendation.
As a conclusion: consider the recommendations, but think about the real situation you have to challenge. Sometimes it’s really worth to leave the common paths and trying something new 😉
You make a very good point here and we find that more CF apps are interfacing with outside work horses like the data warehousing appliaction you mention here.
Hi Kai,
This is one of my favorite topics! 🙂 You would be amazed at how many CF developers/admins I speak with that install ColdFusion and never even bother touching any of the settings at all in the CF Administrator, other than just adding their datasources. Then there’s the other end of the curve where people set Sim Reqs equal to the total number of users they expect to have connected at any given time.
Here’s some of my related blog entries:
http://www.talkingtree.com/blog/index.cfm?mode=alias&alias=CFMX7JRunSimReqs
http://www.talkingtree.com/blog/index.cfm?mode=alias&alias=ContextSwitchingBad
http://www.talkingtree.com/blog/index.cfm?mode=alias&alias=CFStability1
http://www.talkingtree.com/blog/index.cfm?mode=alias&alias=CFStability2
Doesn’t this simply point to a bottleneck in the database that needs to be resolved? Increasing the number of threads to that level is greatly *reducing* the efficiency of the CF application servers. Its only because the database is performing so abysmally that increasing the thread count to such levels is the lesser of two evils.
But heh, what am I saying… sometimes the client is always right and you got to do what you got to do in some situations 🙂
Wow, what a feedback 😉 I’m not used to this 😉
Let me comment on some points:
@Mike: Well, it makes sense a lot to do that. Even as some data warehouses bring their own technology to build web applications, using ColdFusion is a pretty good approach to bring all things together.
@Steven: I know, I’d say 95% of all ColdFusion users don’t touch their admin settings, not to mention “advanced” stuff like XML config files or even JVM settings. Not to blame someone – but I saw a lot of servers you mentioned as well: putting in 1000 simulteneous requests without timeout settings and wondering why all this stuff doesn’t work well.
Thanks for the links, I’ll get them sorted in this comment a bit.
@Geoff: Well, yes, well. As I stated in my email, it’s some sort of responsibility issue. You have different people, different departments, too few communication etc. To bring it to the point: Under the given circumstances it was the best option to do it like this. In an optimal world, I’d prefer to re-engineer a lot of different things 😉
GC and JVM tuning is a very interesting topic and I love playing and adjusting all those settings. Depending on the point of view, luckily (for the company I work for) or sadly (for all the guys running CF on wrong or not optimized settings) there are tons of people out there who just ignore the necessity of really administrating a server, or – and that’s even worse – don’t have any idea how to do it properly because nobody told them.
But basically your point is 100% correct. In a lot of situations it’s always ColdFusion that is slow, buggy, stupid, not open enough etc. Other options usually are faded out of the view and the research on given issue.
This might be related to the fact that CFML as the core thingy of the CF infrastructure is simple and easy and that it allows you to do a lot of bad things during development. So – fast to market with your app – but not well designed and developed. Well – not to generalize all CF developers – but, there are several apps out there developed like this.
But then – given an increase in load and stress on the machine(s) during the apps’ lifetime, nobody thought about possible implications – welcome to my world 😉
Sorry I’m hogging your blog. Steve and Geoff both make great points, Steven has blogged some great stuff along the lines of the Admin side of CF and deeper, Garbage Collection for instance. The whole subject of J2EE JVM-Server admin and not just the CF Admin gui is an incredibly dense and complex subject. Geoff is totally right of course, if the resource that CF is relying upon is inefficient or unresponsive there is not much that CF can do except try to mitigate that at the client end via timeouts etc. Sadly though, CF usually gets the blame for an unresponsive site even when it is a third-party resource actually causing the issue.
hi I liked a lot I am also impassioned by flash ahhh already taking advantage with me does to work with texts encouraged thing of this type I am beginner still I would like some clues I am of the brazil are paulo thank you at once
One of the biggest lessons to learn is that more is not necessarily better (and nor is less!). I posted some entries about performance of the asynchronous gateways under load being dramatically affected by the number of threads allocated to the gateways – which is similar to the simultaneous requests setting for HTTP requests. If you have a CPU-intensive CF process then setting the number of threads lower than “expected” can produce better performance (less contention for CPU between competing threads). The tough call is when you have some processes that are horribly CPU-intensive and some that are always waiting for external systems. That’s when you have to start considering multiple instances and partition the processes according to their CPU curve.
And then of course you have the joys of GC and JVM tuning on top of it all… 🙂
What about in an enterprise configuration where there is not max sim reqs setting? How do the number of requests get controlled?
Comments on this entry are closed.