Contents
CIOs and their teams go to great lengths — and expenses — to put together the perfect, pristine web app.
Yet things can go awry. Some web apps don’t live up to their potential. Happens in ColdFusion, like any other language. I see it all the time doing my ColdFusion consulting work.
These problems become apparent immediately. Resist the urge to blame ColdFusion itself. Especially when stretching your app’s ability to cope with high traffic.
In fact, a web app that goes haywire during a peak load of traffic can betray many other problems.
In this article, you will learn:
- The first sign of trouble for any web app.
- The four biggest reasons your app crashes.
- How to solve these issues.
How can web apps suffer?
Web apps are imperfect little creations — much like the developers that code them. They grow and change as their roles evolve and expand. And all those additions and reconfigurations open the door for errors.
Left alone for too long, these web apps can do more than just have a glitch. They can suffer to the point of driving away users. The biggest symptom of an app breaking down is “The Wall.”
My friend and fellow CFer Mike Brunt describes The Wall on his blog, the CFWhisperer, calling it “that perfect storm of occurrences that suddenly and within seconds brings a web application to its knees.” To put it in layman’s terms, it’s a crash.
The Wall is also the first giveaway that something is amiss with your app. But first, it’s important to know the causes.
The wall is a stacking up of all available application threads at once. You can almost see it coming. Its first symptom is a sudden and dramatic dip in performance.
Several factors can cause it:
- A successful marketing campaign.
- A major event unexpectedly drawing attention to your web app.
- A successful launch drawing in more users than you expected.
Any of these, or several in tandem, can send your app careering into The Wall and crash it. It’s caused by an unanticipated load.
The Wall is a symptom, not the illness
An app crashing under heavy loads is an all-encompassing menace that sometimes uncovers other problems in your ColdFusion app. These potential problems include:
Software configuration problems
The initial setup of ColdFusion is key, setting the parameters for almost all the other work and products you make with the app. If you didn’t install all the bits and pieces of CF properly, you could set yourself up for a date with The Wall.
Poor network configurations
A crash could be a sign your app and servers aren’t communicating. Making sure your network is configured properly could spare you a lot of headaches.
Poorly optimized software code
The code itself could smell. Whether it be bugs, inefficiencies, or deadwood, poorly written code grows slower as more people use it.
Insufficient hardware
A slowdown caused by a surge in traffic could mean your tech specs need to be refreshed and upgraded. From your server blades to the machines and hard drives you use.
Any of those problems amounts to six major areas that can become problematic in your ColdFusion web app, over time or suddenly. If left to fester, they can ruin the user’s experience in several ways:
- Functionality — the nuts and bolts of the app behind-the-scenes can go haywire, becoming increasingly difficult to manage.
- Usability — a person’s ability to complete a task using your web app is prohibited, if not stopped altogether. This, eventually, drives users away.
- Interface — the interactions between the application, network, and servers can become entangled until eventually the difference between the user’s intention and the app’s execution do not align at all.
- Compatibility — its ability to work on various browsers suffers, forcing users to guess which is the best browser for your web app.
- Performance — speed can dwindle and eventually slow to a crawl.
- Security — a collapse in all other systems can also leave an opening for nefarious types who’ll gladly walk away with precious user data.
The Wall, however, shouldn’t be an accepted part of life as a CIO or CF developer. It is possible to build infrastructure that can cope with nearly any load.
How to improve your infrastructure
The best defense against a misfiring, flailing app? Tests galore.
You need to simulate worst case scenarios with your app, attacking every conceivable front so that nothing catches you by surprise.
Test your code every way you can, following Mike Brunt’s proven technique: test all code mercilessly, and don’t release it until it passes every test.
Which tests should you run? I recommend this process:
- Functionality testing: make sure your application actually works, especially links, forms, cookies, HTML, and workflow.
- Usability testing: check if users can navigate your app and complete a task easily.
- Interface testing: make sure all interactions a user may have with your app are executed without major glitches.
- Compatibility testing: ensure your app works well on all devices and platforms users may have, whether that be an operating system or mobile browser.
- Performance testing: ensure your application remains responsive under all potential work loads and stress.
- Security testing: make sure access to your app’s inner workings, especially user data, are sealed and guarded from anyone who may try to break in.
But those rudimentary tests are not all. My friend Mike Brunt has his own yeoman’s to-do list to keep your app from suffering under a heavy load:
- Test the load from the right location. Mike describes this rather simply: “Load-testing will typically start from the wrong location; where the user sits, which is where we should end up, not where we should begin.” Instead, start looking at the network-end of the app and work towards the user side.
- Estimate the load properly. Give yourself a realistic idea of the number of anticipated users of the app, before you even get started writing it. This number may be easy to guess. If it isn’t, err on the side of overestimation.
- Make a baseline performance number, for instance, all requests must complete within four seconds. You want a minimum response time to aim for in your app.
- Now combine that performance number and your estimated load. Test and rejigger your app until you achieve the performance number with 150% of the anticipated load.
- If you hit “The Wall”, then the anticipated load is off. Reset it and try again.
There’s one sure-fire way to see what’s happening in your CFML, and it’s one I preach often when I’m working as a ColdFusion consultant. Check your logs early and often!
CF’s logs offer a wealth of information about the state of your web app and server, according to Brunt. When you’re troubleshooting and can’t seem to find the problem, your logs can often show you where to look. For example, this log offers information about ColdFusion and its main dependency points.Standard non multiple instance install
{drive}\{coldfusion root}\runtime\logs
Multiple instance install
{drive}\JRun4\logs
Also, use “enhanced metrics logging”, which keeps a tab on many threads and memory. It can be a godsend when troubleshooting.
You’ve invested the time, energy, and the company's cash into building a functioning, pristine web app. But systems fall apart in myriad ways. By knowing the most common faults accidentally baked into web apps, you and your company can avoid the hidden costs and lost time associated that come with fixing someone else’s mistakes.
Michaela Light is the host of the CF Alive Podcast and has interviewed more than 100 ColdFusion experts. In each interview, she asks "What Would It Take to make CF more alive this year?" The answers still inspire her to continue to write and interview new speakers.
Michaela has been programming in ColdFusion for more than 20 years. She founded TeraTech in 1989. The company specializes in ColdFusion application development, security and optimization. She has also founded the CFUnited Conference and runs the annual State of the CF Union Survey.
And to continue learning how to make your ColdFusion apps more modern and alive, I encourage you to download our free ColdFusion Alive Best Practices Checklist.
Because… perhaps you are responsible for a mission-critical or revenue-generating CF application that you don’t trust 100%, where implementing new features is a painful ad-hoc process with slow turnaround even for simple requests.
What if you have no contingency plan for a sudden developer departure or a server outage? Perhaps every time a new freelancer works on your site, something breaks. Or your application availability, security, and reliability are poor.
And if you are depending on ColdFusion for your job, then you can’t afford to let your CF development methods die on the vine.
You’re making a high-stakes bet that everything is going to be OK using the same old app creation ways in that one language — forever.
All it would take is for your fellow CF developer to quit or for your CIO to decide to leave the (falsely) perceived sinking ship of CFML and you could lose everything—your project, your hard-won CF skills, and possibly even your job.
Luckily, there are a number of simple, logical steps you can take now to protect yourself from these obvious risks.
No Brainer ColdFusion Best Practices to Ensure You Thrive No Matter What Happens Next
ColdFusion Alive Best Practices Checklist
Modern ColdFusion development best practices that reduce stress, inefficiency, project lifecycle costs while simultaneously increasing project velocity and innovation.
√ Easily create a consistent server architecture across development, testing, and production
√ A modern test environment to prevent bugs from spreading
√ Automated continuous integration tools that work well with CF
√ A portable development environment baked into your codebase… for free!
Learn about these and many more strategies in our free ColdFusion Alive Best Practices Checklist.