Pete FreitagCFThread - Don't Abuse It
By Pete Freitag
I love the fact that you can now create threads with CFML in ColdFusion 8, however as Spiderman can tell you with great power comes great responsibility.
Using threads can increase the performance of your application, however using threads can also decrease performance. And the problem is that CF8 makes it oh so easy to create threads.
One of the potential performance problems you can run into from using threads is called context switching, which can be explained as follows:
- Your boss tells you to work on Project A at 8AM
- At 8:15 your boss tells you you need to work on Project B, so you close all the code you were working on, and open up Project B.
- At 8:25 you need to fix an important bug in project A.
- At 8:30 you get a phone call about Project C, you have to pull up those files.
- Back to project B at 8:35, project A at 8:40, and project D at 8:45
How could you get anything done under the above circumstances? Well computer processors have trouble with that exact problem as well, and they call that context switching. As threads take turns executing their previous state or context must be loaded again when execution of a thread switches between threads. Process and thread scheduling is actually one of the most important parts of an operating system, and includes very well though out algorithms - it's the sort of thing people do their doctoral thesis on. You can read more about it context switching on Wikipedia.
The cost of creating a new thread, is another performance issue associated with using threads. In ColdFusion this is mitigated a bit by using a thread pool, but you can still create performance problems if too much time is spent creating new threads. There is a setting in CF Administrator which limits the number of threads that can be created with CFTHREAD, if this value is reached, the threads will queue up, and wait to execute.
The third issue you may face is shared resource contention. Suppose you have a lot of threads trying to use a shared resource, such as an application variable or file. You can create a bottle neck due to the locking / access synchronization of that resource.
In the end the only way to know if your application will benefit from using threads is to test and tune it under load, which is a something most developers don't do. So I am wondering if we will start to see a lot of performance problems due to overuse of the CFTHREAD tag, what do you think?
CFThread - Don't Abuse It was first published on August 07, 2007.
If you like reading about threading, coldfusion, cfml, cfthread, context switching, threads, coldfusion 8, or performance then you might also like:
- How CFThread Can Help OR Hurt Performance
- Implicit Structure Notation ColdFusion
- 10 Most Useful Image Functions in ColdFusion 8
- CFImage Effects Library for ColdFusion 8
The FuseGuard Web Application Firewall for ColdFusion & CFML is a high performance, customizable engine that blocks various attacks against your ColdFusion applications.
CFBreak
The weekly newsletter for the CFML Community
Comments
@Ben - I would think that LOW priority threads would suffer less from context switching, but the extent would probably depend on the thread scheduling algorithm used by the Operating System, and possibly the JVM's threading implementation. Reguardless, though I would say it is probably a really good idea to use a low priority thread for any thread doing a background process that you don't need to wait for.
That brings up an interesting use case for CFTHREAD, suppose you have a scheduled task that runs once a day, it may be a good idea for that task to run in a low priority thread, because otherwise the task will run in a normal priority thread.
Now adding cfthread, I could easily see a novice or even an intermediate programmer spawning threads everywhere just because its a fun new toy and, just like you said, never load testing. Once the site gets more than 5 hits, it locks up. And because its a ColdFusion site, CF will be blamed for the lock up, when in reality, the problem is with the programmer (the code), not CF
I suspect that this may be a contributing factor to only allowing 2 concurrent threads in the Standard License (i.e. programmers with less experience?)
At least that was my understanding...
http://www.adobe.com/products/coldfusion/pdfs/cf8_featurecomp.pdf
Thread pool and thread creation are mutually exclusive...
Lowering thread priority has zero impact on context switching overhead...
And so on, and so on...
Anyway, each impression needs to execute about 20 threads that query a third-party xml feed and then join them and display the results. So far it worked well for us when we had it at 5 threads per request. But now we do 20-30 requests and the servers are both crashing every 6-12 hours.
It seemed like the memory hit nearly 0 gb on our servers and then CF stopped working. I investigated all memory leak issues on the web and came up short of how that could be anywhere connected to cfthread.
I installed Oracle's BEA JROCKIT jvm to replace the SUN jvm, and the memory leak issue disappeared, probably due to their superior garbage collector. But now their JVM is crashing for other weird reasons due to CFQUERY - well not CFQUERY , because we actually query our database via Java functions since there were other CFQUERY pooling performance problems in the past. So our software is really tuned and customized to work the best it can on the least amount of hardware.
What I added to our CFTHREADs is the action=terminate after all threads are joined, which we haven't been doing so far. So far the servers have been stable last few hours but we'll need more time to actually determine if that was the issue or not.
So I am just curious what everyone recommends and if anyone experienced similar memory leak problems with cfthreads?