How to resolve Performance concerns with your hosted Web-site
How to verify the performance of your hosted website.
The trouble with using a data centre is the service provider does not always respond to queries. I was in recent times asked by a client look at an issue concerning a hosted website.
The problem was a website which was running slow. I wanted to know what they had changed recently thinking that something they had done may have caused a problem. They told me that they hadn’t made any alterations of late, it had simply started to perform poorly suddenly. They did state that some time back they had made performance improvements on their website by by installing compression and by making any images on the site more efficient. They had checked the performance after these changes and the website was running well and had been for quite some time now. The reduced performance had started a couple of days earlier and they were certain the performance problem was due to the data centre where the website was hosted.
A study was started to see what was occurring. The opening thing I did was to execute a ping. This can be initiated from the command window (from the start windows prompt, type ‘cmd’ and enter. The command itself is simply “ping www.testingperformance.org” This generates 4 requests to the website each with a packet size of just 32 bytes. It’s pretty small, and the response should give you a good idea of latency. Of the 4 hits, twice out of 4 the replys timed and the remaining 2 took over half a second. That is not very quick. There are a variety of options with ping. “Ping -l 200 www.testingperformance.org” will ping the website with 200 bytes. While this is still very slow, it can be increased quite simply to 100Kb which is more realistic of a big web page.
As I was in Britain and the website was located in the North America, I wondered if the latency could be owing to the distance across the Atlantic. To answer that query, I ran a trace route. The format of the command is “tracert www.testingperformance.org” This should demonstrate the various hops that are made when accessing from a workstation or laptop to a server or website. What I could see was that the last 2 or 3 jumps (out of about 20 jumps) were extremely sluggish. It was possible that these hops were in the data centre itself.
I conveyed this information to the data centre and said, look, here is substantiation, are these hops with reduced reply times caused by your equipment? The data centre people in due course contacted me back and stated, they could not tell a lie, the answer was no, it was not them. Well I knew it wasn’t me, and I knew it was not my ISP, and the data centre said it wasn’t them, but I didn’t believe them.
Scouring the net, I located some tools I considered should help, one was named IWEB. I downloaded the tool and it checked the homepage on my website for an interval of time. The results showed response times varying between 2 seconds and 25 seconds. I sent this data back to the hosting centre and asked them to make a statement.
“Oh yeah,” they said, “oh there has been a issue with {one of the} sites on our hardware, it has been receiving lots of hits recently.” “hang on a second,” they said. Half an hour later, my clients site was delivering 1 – 2 second response times again. The assumption was we had been moved to a better performing server. Well, I guess we were ok, but there remains around 90 – 100 websites still hosted on the hardware with performance issues? It wasn’t that we complained, it was showing the evidence which managed to settle the issue for us, thanks to IWEB.