One submission for a presentation I suggested to Adobe for Max 2009 was called, 10 Steps To A Stable and Performant Web Application and I am unsure whether they will be interested in such a presentation.  As I believe it would be beneficial to get such information out to the community at large, I am going to blog about me thoughts and recommendations.  What I put in these articles is based on what I do, me overall methodology in running a team dedicated to designing or fixing web applications so that they perform and scale well.  There are 10 major phases to this when applied to existing applications and this post is the first of 10 successive ones which I genuinely hope will be of help to the community that has been good enough to provide with a good living.

Phase 1: Investigating current production. Typically when a client calls upon us it is because they have a problem in production.  Eventually we hope to have some sort of test environment where we can load test changes-fixes before they go to production, however at first we want to look at recent logs to see if we can identify any major indicators of issues.  What we request is either access to or copies of the following logs.  As a note point, if we are able simply to get copies we are not usually interested in anything further back than 7 days.  The reason for this is that sometimes problems get fixed and either forgotten about or not mentioned because of embarrassment etc.  Going too far back can lead to basically chasing shadows.  These are the logs we request initially, also note anything in { } needs to be substituted with the actual information...

ColdFusion Standard Install or Enterprise Non Multiple Instance Install - {drive}Coldfusion8\logs
ColdFusion Multiple Instance Install - {drive}\JRun4\servers\{instance}\cfusion.ear\cfusion.war\WEB-INF\cfusion\logs

• Application.log (This is still valuable, in essence all that goes into here is warnings and errors so all could be relevant).
• Server.log (This will show us all ColdFusion restarts and also possibly long running requests if enabled in the ColdFusion Administrator).

ColdFusion Standard Install or Enterprise Non Multiple Instance Install - {drive}Coldfusion8\runtime\logs
ColdFusion Multiple Instance Install - {drive}\JRun4\logs (all servers-instances go into this directory and the logs carry the name of the instance-server).

• coldfusion-out.log, this may sometimes be cfusion-out.log (The system "out" log is a standard Java log and really is the catch-all log.  There will be lots of good clues in there although it can get buried if someone has decided to log all under the sun. There are ways to make this better and I will cover this in step 2 of this series under enhanced logging.  Look for out of memory errors in the -out.log in particular, we may also get ColdFusion restart information here too.  This log is really useful).

One other thing that we pay close attention to at this stage, is recent ColfFusion restarts.  As I mentioned above, the restarts are sometimes in the "out" log, if so that is helpful as we like to look at what was going on at the time of restarts, particularly right before one.  If the restart information is not in the out log then we can refer to the Server.log and compare date-time stamps.

So this is the first step in our process, we want to know what is going on now, where it matters; in production. In the next step and the second blog posting we will investigate enhanced logging and what we can get from that.