Ike.ninja

Ya ever have pingdom or some other monitoring site tell you your site is down? Then you ask your host about it, and they say that the site has been online the whole time?

Your hosts are probably telling you the truth. If you are using monitoring that relies on pings to see if the site is up or not, then you may not be getting 100% accurate information. A ping is not a priority to a web server. So if you server is busy, your server is going to serve the web page instead of responding to the ping.

If you load rises high enough, then your pings will start being rejected or timing out. This isn’t saying you are out of the woods. This may mean that your server is not tuned properly or you need to upgrade as you are pushing the limits of the server. I would have your hosting company check the optimizations of your server software. These can often be tweaked to handle more traffic, or limit the traffic to what your server can handle.

Most servers have some type of built in monitoring software that will help to ensure that your site is online. Cpanel servers use tailwatch and chkservd to ensure that all services are running. They will attempt to restart the service if they find it unresponsive. You may have seen these e-mails about clamd or exim failing. These are the most common services I see fail.

On cPanel there is a plugin called munin that you can have installed via WHM. This is a decent statistics program to watch over your server. It has a bunch of graphs that make things fairly easy to read and understand.

It is a good idea to monitor the health of your server as downtime can be critical. However if you are not using the right type of software you may be chasing a lot of false positives rather than working on things that need to handled.

What kind of monitoring software do you prefer for your server?

New York Internet looks set to make it through the aftermath of Hurricane Sandy with barely a scratch on its uptime or performance.

NYI’s New York City datacenter is just a third of a mile away from the 75 Broad Street datacenter (in evacuation Zone A), which flooded during Hurricane Sandy. NYI is crucially further uphill, in Zone C, and was out of reach of the storm surge. Despite widespread power failures within the area, NYI has so far managed to continue operating without suffering from any outages:

Demand for fuel is very high in the areas affected by the storm. Phillip Koblence, founder of NYI, said that poor availability of gasoline for staff to get to and from datacenters was his worst problem, followed by sleeping and washing facilities. Queues to get gasoline were reportedly two miles long, and vehicles containing fewer than 3 people were not being allowed into Manhattan between 6am and midnight.

Koblence told Netcraft that he had no power or water at home, and difficulties getting food anywhere near work were also adding to the problems. NYI expected commercial power to be shut off as the storm hit, and its New Jersey and New York City datacenters have been running on diesel generators since Monday.

NYI estimates that its 21st floor generator tank in Manhattan can last for 36 hours, while its 8th floor generator can run for more than 3 days. The Bridgewater datacenter in New Jersey is believed to be capable of lasting at least 10 days on generators, far longer than the times between each fuel delivery that the company has been sustaining this week.

Commercial power is expected to be restored to the datacenters late on Saturday night, although NYI plans to remain on generator power until the commercial power supply becomes stable.

Live performance graphs for www.nyi.net can be viewed here.

Datapipe was the most reliable hosting company in October, impressively responding to all requests throughout the month, despite being in the area most affected by Hurricane Sandy.

Datapipe’s corporate offices are based in the heart of Jersey City, very close to areas where analysts had predicted a 100% probability of a storm surge higher than 6 feet. The southern tip of Manhattan eventually experienced a storm surge of

13 feet. Datapipe founder and CEO Robb Allen told Netcraft that the effects of the storm were also felt as far inland as Somerset, where Datapipe’s
New Jersey datacenters are based.

After the grid became unstable on Monday, Datapipe switched to generators for their datacenter power supply. Even though their diesel reservoir was large enough to last at least four days, Datapipe also stationed additional fuel trucks on site in case roads became impassable.

Allen noted that previous events including grid blackouts, Hurricane Irene and 9/11 have all helped the internet connectivity and hosting industry in the US north east be better prepared for emergencies, though that there is currently a lot of strain on fuel delivery systems.

Datapipe’s performance and uptime remained remarkably calm before, during, and after the storm, in stark contrast to destruction depicted in photos taken during the event.

When there isn’t a storm brewing, Datapipe runs its United States data centers on
entirely renewable energy and is recognized by the Environmental Protection Agency as a
Green Power Partner. Datapipe’s other US datacenters are located in San Jose and North Virginia.

Datapipe also has datacenters in Iceland, London, Shanghai and Hong Kong. The location of the
Iceland datacenter allows for free cooling and runs on 100% renewable power using only
geothermal and
hydroelectric energy sources. The physical infrastructure has been built with steel instead of concrete, making much of it recyclable at the end of its life.

Netcraft measures and makes available the response times of around forty leading hosting providers’ sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer’s point of view, the percentage of failed requests is more pertinent than outages on hosting companies’ own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.