We are asked to help clients with various issues at various stages. Sometimes we are brought in when an application is simply being planned, sometimes just before launch or enhancement. This blog piece covers the times when we are brought in to pinpoint application slow-downs or failures.
As I have mentioned in previous blog postings, the first thing I always want to do when trying to help a client with application slow-downs or failures is to see the recent Production ColdFusion and JRun logs. The logs I focus on can depend on what kind of install, what operating system and also if there are any custom logging settings. If there is a {server-instance}-out.log I look there first. I never go back further than 7 days unless the client has a specific reason for me to do so.
So, what does this have to with Load-Testing? Please read on, if you wish. The logs I mention above will definitely give us pointers to what is going wrong, if we add Metrics Logging and Verbose Garbage Collection logging we will see more detail on that. All of this will give some overall indications of the system state. For instance, if there are many different templates, events or fuseactions in the logs I would suspect overall environment problems. If it is a just a few templates, events or fuseactions repeating over and over again then that is usually indicative of specific code issues.
As a note point, in frameworks such as FuseBox, Mach-ii or ModelGlue knowing what actually ran is more difficult and we need to capture the URL Query String. Both FusionReactor and SeeFusion are of great assistance in this respect. Hopefully the client can provide a testing environment, and in that case we would want to use a load test tool.
That test environment should be as identical to Production as possible, and it is critical that the code be the same. From the pointers gained from the Production logs and hopefully with some guidance from the client, we then create load-test scripts that exercise the code that we saw causing issues in Production.
We almost always start by tuning the JVM, particularly if there are indications that the site overall is slow. One last critical point; we look very closely at is the errors in the logs on the test environment. We want to see the same or very similar errors to those seen in Production otherwise we have some fundamental differences which will make it more difficult to achieve success.
DougHughes.net 