This is a topic we have to deal with and attempt to explain quite often, and after some 12+ years supporting ColdFusion, and dealing with hundreds of developers on all levels, ranging from beginners to gurus, one thing we have come to learn quite well is that most developers do not really understand how things work on the server side.
They know how to write code and upload it to the server, but most things beyond this tend to be somewhat of a “black box”, and specifically the majority of CF developers also do not understand how ColdFusion really works and how/why it works differently from other scripting languages like PHP or Python or ASP.net.
Unfortunately this lack of knowledge often results in the wrong type of hosting being used which can be very detrimental to a clients website performance and security, especially in a shared hosting environment and unfortunately tends to also result in “the finger of blame” being pointed at the hosting provider whenever there are problems, which often results in the pointless moving of sites between one host and another, which does nothing to address the inherent issues. So hopefully this article will help to enlighten and inform as well as alleviate some of the misconceptions about ColdFusion hosting.
To put it simply, ColdFusion is a Java application, it runs on Java Servlet Engine (such as Tomcat) and this is where the problem lies, with Java rather than ColdFusion.
It is IMPORTANT to understand that Java (and thus ColdFusion) is intended as an enterprise solution and as such is intended to run on dedicated hosting solutions and was never built for, or suited to, shared hosting, due to the way it works, so when it is used in a shared hosting environment it tends to have performance issues and also has some security issues as well.
How ColdFusion processes web page requests
When we look at other common languages such as PHP, Perl, asp.net etc, these run as an NSAPI/ISAPI or CGI process, so, every website on the server spawns its own process to handle the requests. So, if there are say 20 PHP sites then there are 20 x PHP processes running (think of this like 20 separate instances of ColdFusion).
So if site1 crashes php or ASP, it will generally have no effect on any other site because they are running php/ASP in a separate process. Of course there are occasions where these processes can end up killing the web server as whole, but this is far less common and happens very infrequently.
ColdFusion on the other hand does not run this way.
ColdFusion instead runs as a service (like your anti virus software for example).
This is the equivalent of a single process in the CGI/ISAPI world. This means that essentially, every single web page on every single website on the server is going through the same process, and the end result of this is that any single website can cause problems for all the others.
Just as when your anti-virus software runs, it can slow your computer down and make it unusable for you because it consumes all your system resources.
Here is a diagram to illustrate.
Imagine the following (very common) scenario.
Lets say abc.com makes a cfhttp request to an external web service at xyz.com to get syndicated content for its pages.
The web service at xyz.com goes down, which means all the pages on abc.com are now, potentially, going to have timeouts waiting for a response. On a shared server this can very quickly result in all the ColdFusion maximum number of simultaneous requests to be consumed, and subsequent requests will then become queued behind them. The result of this is that every other Coldfusion site on the server now becomes slow as well, as all their page requests have become queued behind the problematic site(s), and are now likely to also timeout as a result if they sit in the queue for too long.
An even worse scenario is where native java requests are concerned, such as database queries as these cannot be killed automatically, not even with FusionReactor, so will never timeout. If a web page hangs in the middle of a database query because it is waiting for a response back from the database server, then this request will not ever timeout and will hang indefinitely, thus 1 cf thread is now permanently used up and no longer available. If this happens 10 times, now 10 cf threads are gone and no longer available to anyone else. If the “maximum number of simultaneous requests” on the cf server is set to 10, then you now have 10 requests hung and 0 requests left and so the server will no longer be able to serve up any more ColdFusion pages and subsequently all websites on the server will now hang/timeout until the service is restarted.
If the original problem still exists then restarting the CF server will also not help, as the issue will simply return and continue until all the requests are again used up and all sites start to hang. The only solution at this point is to find the site causing the problem and turn it off.
But my code has proper error trapping and caching and stuff, so this doesn’t affect me, right ?
Wrong, I’m afraid. On a shared server it doesn’t matter how brilliant your code is, or how well you have performance tested it, or how much error trapping you have. This does not stop the other sites on the server from causing you problems or you causing them problems.
You could be lucky on a shared host for months, or even years, if you are on a server that doesn’t have many websites, or simple sites that are not problematic (at the moment), but it only takes one poorly written app to bring CF to its knees.
It is also important to realize that (in our experience), almost nobody using shared hosting has ever done any kind of load testing or performance testing on their website and, in most cases, do not even know what this means or how to do it, the result of this is that web site owners have no idea how their site will perform under load. This results in another very common scenario which usually begins with a statement like, “Nothing has changed on my site and it has been running fine for years, so it must be your server”.
Again this is totally irrelevant in most cases, sure your site (or any other site on the server) may well have been running fine for years with 20-50 visitors per day, but what happens when it suddenly gets 1000 visitors per day as a result of some marketing or media attention? Or if it starts getting hit by search engine bots? (which is very common) Suddenly this once stable site falls over horribly, due to poorly written or legacy code which simply cannot cope under load, as it was never load tested.
Let me give you an analogy.
You have a reliable little moped, you have been driving it around town for years with no problems at all and it has served you well, but it has never gone above 40 MPH. One day you need to take it on the motorway for the first time ever, so this would be the first time your reliable little moped has ever gone above 40 mph, but unfortunately it seems it was never built for this, and once you hit 70 mph the engine overheats and the bike stops working. You are stuck right in the middle of the motorway, and are now causing a tailback as cars start to queue up behind you. The only way to resolve this problem, is for someone to remove you and your moped out of the way so that traffic can start flowing again.
When your engine cools down, you can probably get going again, but once you get up to 70MPH, the same problem with occur.
Everyone by now is aware of the prolific CFIDE hack which affected many CF servers around the world, and which we blogged about HERE. This was only possible because CF runs as a service, and because that service runs under the SYSTEM account by default, which has full file system access, which allowed the uploaded hack to access every part of the server. If CF worked like a CGI/ISAPI application (as it did in the days prior to CF6 before it became a Java application), the effect of this hack would have been very limited, as on a properly configured server, the hack would not have been able to read/write files outside of the web root.
While there are ways to lock down ColdFusion (and yes we do this), this is more to protect the server and does little to protect websites from one another, again due to the fact that ColdFusion is JAVA and runs as a service, so on a shared server there is simply no way to fully 100% secure your site from being accessed by the code in other sites what are written in CFML or any other Java application, not even when using security sandboxes, as any competent developer can easily circumvent these sandboxes, obviously we are not going to document how though.
So to put it bluntly, if you are running an eCommerce site and storing customer details and/or card details, or any other kind of private or personal data, then you are putting this data at risk on any shared server, period. If that server runs any kind of Java application server which runs as a service (such as ColdFusion), then the risk is greater.
Other common causes of performance issues
There are quite a few other common issues that occur on shared hosting which can cause problems for everyone.
- Client variables
A lot of developers will enable client variables in their code even though they do not use them, and worse will set them to use the registry or a database by default.
When using the registry, this fills up the servers memory, and can cause it to crash.
When using a database, this can affect performance considerably and make the site slow. A database bottleneck can also affect other sites on the server.
- Database bottlenecks
Badly written database queries, lack of caching or poorly designed databases will result in performance bottlenecks, which will get worse as a site gets more traffic.
These performance bottlenecks will result in pages taking too long to execute, which results in timeouts, which results in queued requests. The end result as above is that all other sites end up going slow.
When content and data is cached, this means the application does not have to go and get it each time for each page, which improves performance.
Lack of caching can cause performance issues, especially with databases when grabbing large chunks of data, or when connecting to external feeds or web services for data.
again this results in timeouts.
- Too many requests
On a shared server, remember that you are sharing everything with hundreds of other customers websites. This can easily overwhelm ColdFusion due to the way it works as the maximum number of requests can easily be exceeded when things get busy. If another eCommerce website on the server is having a major sale and has increased their traffic 10 fold, this will have an impact on everyone else.
But Railo is better right ?
When talking about the issues above, ultimately, No, I’m afraid, as Railo is also a Java application and so works the same way as CF, so the primary issues mentioned above, apply to Railo as well.
Railo is however an improvement over ColdFusion in many other ways.
Such as in that the security sandboxing, which is automatically applied at website context root level (if you set this in your Railo server admin) and just works, and does not require admins to setup sandboxes for each site as with ColdFusion which is a sandboxing nightmare, which makes Railo better for shared hosting. However, the sandboxes, like ColdFusion’s, only sandbox CFML and do not secure Java code.
Railo also has a per site web admin, allowing all customers to admin their own site, which is again a big improvement over ColdFusion, which has a single Admin which must be administered by the host, and customers cannot have access to this. There is also no CFIDE folder, which has been the cause of many problems with ColdFusion.
So by using Railo you don’t have to rely on your host, you can pretty much do everything yourself, which is a big plus. So overall, Railo is a better solution in a shared hosting environment.
So what’s the solution?
The only solution is to do some research, educate yourself and use a bit of common sense, and consider, how important is your website to your business ?
As I mentioned, ColdFusion is, and always was, intended to be an enterprise solution, and as thus, run on dedicated hosting solutions. It was never intended to be used for shared hosting and is not built to do this. Don’t forget that ColdFusion as an enterprise solution also has a hefty price tag (£6,800 for the enterprise version), so ColdFusion hosting is always going to be more expensive too.
So the simple answer is, use the right tool for the job. CFML is a great language and ColdFusion/Railo are great tools, when used correctly, you wouldn’t use a chisel to hammer a nail right ?
If you just want to run a blog, personal website, or a simple brochure ware website and up-time/performance is not important to you, then you are a candidate for shared hosting, and these these types of sites are best served by somehting like WordPress for example, or other free open source site in a box/CMS type systems. For this type of site ColdFusion really is overkill.
If you run an eCommerce site or any kind of application which is mission critical, is your primary source of income, and needs to be secure, then you are a candidate for dedicated hosting.
If you love CFML and want to use it for everything you do, or have a custom built application, then you should consider the implications, and get yourself a VPS running Railo (or ColdFusion if you can afford it). You then have full control over the security and performance, and also have the option to use multiple CF instances, so each of your sites run on a dedicated instance of Tomcat (or your preferred java servlet container), so you can still run multiple sites but avoid the shared hosting scenario and also lock down the security.
If you have any questions or need some advice or consultancy on this topic, please feel free to give us a call.