Day 256 to 270 – Sat 24th May to Sat 7th June 2014

As I am approaching the end stages of the project, this will be my penultimate post – due to the intense workload I will be placed under.

The most significant issue I came across during this time period was server performance issues. There are over 3 million rows of data on the server, so most queries involving joins would put a significant amount of load on the server. Between May 20th and May 26th 2014, I noticed that the server’s C.P.U was running extremely high for extended periods of time – at around 99.5%. Initially, I thought this performance issue had something to do with my code, so I looked at any looping structures and query joins, but that did not make a difference. In order to save time, I went to Tom Clark, who helped me diagnose the performance issues.

Tom and I communicated over a series of emails to work the issues out, with a hands-on meeting performing some server tweaks. While some Apache server tweaks did not solve the performance issues, I decided to look at query caching – storing frequently used queries and results for quicker retrieval. After modifying the MySQL configuration file to allow query caching, the performance issues ceased to exist.

The graph below represents the web server performance between 8th May and 7th June 2014. The query caching was enabled and running on 26th May 2014. You will also notice that, between the 16th of May and 26th of May, the server load is ridiculously high – while after query caching was applied, the server load dropped off to more acceptable levels.

Server performance – 7th May to 6th June 2014

Server performance - 7th May to 6th June 2014

The image below is an example of what statistics the query caching can record and show – these statistics change over time, as queries are requested and then executed.

Query cache example
Query Cache Example

I strongly believe that I could have found these performance issues much sooner, if I was able to actively monitor the server with an easier-to-understand interface. Fortunately, right after enabling query caching, I installed a server monitoring tool called Nagios – a screenshot of my installation is below (note: this cannot be accessed publicly, for security reasons).

Nagios installation on web server
Nagios Services Panel

Towards the end of this post’s time period, I worked with my project advisor on a series of ‘sanity checks’ – making sure that calculations performed on the project site were realistic. On very little sleep, and with a painful headache, this proved to be a very frustrating task – but in the end we were satisfied with the amendments made to the calculations. With this in mind, we also focused on the front page and changed the wording slightly – to help convey messages etc better. After this was completed, my project advisor gave me verbal confirmation that, in terms of coding etc, the project is now finished (although the technical report, project poster, and a third of the evidence portfolio need to be done).

Below is a screenshot of the front page in its entirety:
Project website front page - final version
As soon as I finished collating this screenshot, I realized there were a couple of spelling/grammar mistakes – these have been fixed on the live page.

So with all this work behind me, I can (at least) relax a little bit more. I still have 1/3 of the evidence portfolio to complete (minus the technical report), the technical report (on its own), the project poster, client maintenance documentation, and final security tests. There is also the administration and processing of surveys to do.

Deadlines for remainder of project (07/06/2014 to 19/06/2014)

  • Client maintenance checklist (11/06/2014)
  • Survey deployed and findings processed (13/06/2014)
  • Technical Report (13/06/2014)
  • Project Poster (13/06/2014 noon)
  • Evidence Portfolio (17/06/2014 noon)
  • Product Panel (19/06/2014 9:50am to 10:05am)
  • Process Panel (19/06/2014 11:55am to 12:20pm)