debugging web site/database lessons.

After spending a frustrating day yesterday working with a client, their web site overload issues, and the hosting “advanced support” I am worn out. The issue: extremely high traffic database driven web site – when moved into the production environment on a dedicated server – would spike the processors’ load to 100% and would then need to be restarted. I got called to help solve the problem. The “advanced support” blamed it on the CMS and that is where I stepped in. The first thing I wanted to see were the server logs. (Apache and MySQL to start) After a long and frustrating time on the phone with the “advanced support” they were finally convinced I knew what I was talking about and gave me shell access to the server so I could tail (tail -f logname_log) the log in order to see what kind of error messages were generated. Mind you – my client had been dealing with the “advanced support” for two days at this point and not once did they look at the log files. Within a few seconds I was able to see the errors that were causing Apache and MySQL to run out of control and within a short while, I had a solution.

The lesson here – and it seems like I have tried to get this across many times before – if you are experiencing server issues of any kind – DNS, email, web, database – always check the logs first. The log files will either tell you what is wrong right away, or give you something to search for on your search engine of choice. The other lesson of the day: if you are have a content management system that uses a lot of database queries on a very busy site – make sure you you are using some sort of caching. (such as the MySQL Query Cache)