Windows IT Pro Magazine’s latest issue, the section “CTRL+ALT+DEL” – a section reserved for funny and odd message boxes that occasionally appear in software – features “Top 10 IT Admin Fears”.  Number 1 is “Fear of silence in the server room”.  Yes that is quite scary.  Number 5 is “Fear that the server running your monitoring software is down (or worse, fear that the mail server is down, and the monitoring server is trying to send you an email warning).”  That too is frightening, but preventable.

The fear of not receiving an email alert when an outage occurs has some foundation, but can be easily insured against.  Here are some suggestions:

1.       Don’t use the mail server you are monitoring to send out email alerts.  Just don’t do it.

2.       Subscribe to a hosted email service that uses basic SMTP to send email alerts through.  This type of service is low cost, easy to administer and has virtually no maintenance involved.  As long as your connection to the Internet is alive, you should be able to send email.

3.        On the machine doing the monitoring, setup and use IIS Virtual SMTP server.  It’s free and as long as your network and Internet connection is alive, you will be covered.

4.       Use a mail server that is on your network, but not on the same machine as the main mail server or the machine doing the monitoring or any of the machines being monitored.  Think of all your servers as boats in a lake.  If any one of the boats starts to sink, would you call on that boat to send out the SOS signal? 

5.       Redundancy: specify two different mail servers to send out email alerts.  Monitoring products like WebWatchBot allow you to specify a primary and fail-over mail server for sending email alerts through.

6.       Alternatives and going old school: Dial a modem.  If network and Internet connections go down, you won’t be able to send email at all.  Go old school and dial up a modem to call someone to let them know that Armageddon is here.

Started having a problem with the generic error message “network cable unplugged” on several virtual machine guest OSs, running on Microsoft’s Virtual Server 2005 R2.  The problem happens infrequently, however, it is difficult to catch without cross-monitoring (one VM monitoring another VM for network connectivity). 

I don’t know why the problem is happening.  A search on Google (web, groups, etc.) does indicate that others have experienced the problem, but there are no solutions that I can find.

My workaround is to simply restart the NIC when connectivity is lost.  To do this, I am using Microsoft’s “Devcon” tool: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272.  Download and unzip the tool to a working directory.  I have a tools directory in place, so I unzipped the files in a subfolder named “devcon”.  Complete path: c: oolsdevcon.  When unzipped, two sub-directories are created, “i386″ and “ia64″.  Most will use devcon.exe in the i386 folder.

To use the tool, you have to first identify the name of your NIC: Right-click on the LAN icon in your task-tray, select “Open Network Connections”, then look for your NIC.  You are looking for the hardware name of the device.  This could be “Broadcom…”, “Netgear…” etc., that will be used to search the list of devices supplied by devcon.  First, create a list of all devices:

devcon.exe findall * > list.txt

The list will contain all of the devices on the machine and their respective descriptions.  Next, open the file “list.txt” in notepad and find (Ctrl+F) your NIC device, for example search for “Broadcom”, or “Netgear”, or one word that describes yoru NIC.  In my case, the device name, the text preceding the description and colon is:

PCIVEN_14E4&DEV_170C&SUBSYS_01D81028&REV_024&2FE911E8&0&00F0

This device name will then be used to disable and enable the NIC from the command line using devcon:

devcon disable PCIVEN_14E4&DEV_170C&SUBSYS_01D81028&REV_024&2FE911E8&0&00F0

devcon enable PCIVEN_14E4&DEV_170C&SUBSYS_01D81028&REV_024&2FE911E8&0&00F0

It’s as simple as that. 

Now, when my network connection goes down, I first assume that there is a problem with the network connection, and restart it.  It’s not a perfect solution, but it will at least prevent some downtime.

In the first part of this series, two main areas that contribute to poor performance were discussed: hardware and software.  Part 2 will discuss other software that can contribute to poor performance.

It’s STILL a software problem

The structure, size, or location of HTML, images, JavaScript, CSS, etc., can make the difference between a page load time of 1-5 seconds, however, there is a bigger culprit for today’s media rich and resource intensive websites: the database.

Let’s face it; websites serve up dynamic content more than ever to ensure a good user experience and to make the website useful.  Databases drive that dynamic content to a large degree and can be the cause of slow performance.  The reasons are clear: databases can suffer from performance problems, stemming from poorly written queries, poorly placed indexes, out of control growth, and generally poor planning from the start.

Middleware can also contribute to poor performance, such as load balancing and middleware. 

In a load balanced environment, it is not uncommon for one or more servers to have software out-of-sync with the other servers.  From first-hand experience and discussions with colleagues, it is not uncommon for one “bad” server to get out of step when a software push/update is made, which can be confusing and difficult to diagnose.  When this problem occurs, it often manifests itself with odd and intermittent errors that appear to the user and not re-creatable to support staff.  It’s a totally frustrating situation.

Other middleware that coordinates transactions or business processes can be misconfigured or simply perform slowly, which can lead to months of diagnosis before a resolution can be made.

So how does one detect, monitor and resolve these types of issues and obtain the fastest and most efficient website as possible?  By monitoring, of course!  By monitoring the three levels of web applications (See this blog post for more: Three Levels of Web Application Monitoring), one can detect the problems before they arise, and resolve them before the customer is ever aware.

So you are monitoring your web application, but are you really covering the 3 basic levels that will fully ensure it is available and responsive?  Monitoring of a web application can be as simple as testing a single web page; however, going deeper and covering your bases is better.

Level 1: Monitor web server availability - if the web server allows connections and returns a response, positive or negative, then it is available.  For example, if you know the ip address or hostname of a web server, you can monitor it with a ping, open port 80, or request a web page. 

At this level, a response is required and optionally, the HTTP status code is checked.  If the status code is not HTTP 200: OK, then it might indicate a problem. 

The actual amount of time it takes to respond is not important.  Almost all website monitoring software and services provide this level of testing.

Level 2: Monitor web page responsiveness - measure response time that it takes to download a specified web page on a web server.  After the condition of level 1 is met, it is important to ensure that a particular web page does not take too long to return HTML to allow the client’s web browser to render the page.

Think of web page responsiveness this way: a speedy page is a happy user.  Think of a slow responding web page from the user’s perspective: they think the website is either down or broken.

Level 3: Monitor web page content.  By far, this is one of the most important ways to monitor a web page and web application.  If the content returned from a web server for a particular web page is not what was intended, then the web application is not doing its job.  The web server can be available and serving web pages in a timely fashion, but, if a web page is returning an error to the user, then the web application has simply failed in the eyes of that user.

In conclusion, when setting up monitoring of your web application, consider covering all three levels.   At the very least, you can be assured that you will know what is going on at all times.

Perhaps one of the more important aspects to setting up a monitoring solution is knowing where to monitor from. 

SaaS (Software as a Service) vendors that monitor from PoP (Points of Presence) around the world, offer a way to analyze performance from those locations.  This type of monitoring can be useful for websites that only have an outwardly facing website, e.g. a storefront, blog, etc.  However, this is not always beneficial for large corporations or organizations that have both internal and external websites that need monitoring for constant uptime.

Intranet applications are often kept within the corporate network and are not visible to the outside world; and, to monitor Intranet applications, it is essential to install software on a computer inside the network. External facing websites may also be located at the same company; but, is it a good idea to monitor them with the same computer that is monitoring the Intranet? Yes and no.

It is always good to monitor external facing websites from an internal location. My suggestion is to compliment this monitoring by setting up a second comptuer for monitoring outside the network or on a different network.

The benefit of this type of setup is the ability to have a fail-over monitoring and response time results for comparison.  If a web application is slow for users outside the network, but not for internal users, then one can easily guess that the failure point is somewhere in between.  It’s just logical deduction at that point.

Most companies with Intranet web applications are concerned about uptime and performance for their internal users but fail to show it.  Since internal applications are typically supported by a very small staff, usually one person, let’s call him John, who also has other responsibilities, monitoring uptime is an often overlooked component because “if it goes down, John will take care of it.” 

Let’s be realistic.  John, your sys admin/dba/support tech/you, is often very busy and is constantly dropping everything to figure out why the Intranet application is down.  When he does stop all his other important tasks to solve the problem, everyone in the company scratches their head, “why is it down?”, “when will it be back up?”, but few actually follow through and look for a better solution than relying on John.

The solution: Automated Monitoring.  No surprise.  The reason for doing it is simple: it can automate the process of detecting downtime and even take proactive measures to get things going again, e.g. restart the web server or database. 

This may seem blatantly obvious, but the fact is that many companies don’t do it.  I find this frankly shocking.  The main reason seems to be that it’s just not that important because it’s a. for internal use, b. it’s not worth the effort because John can take care of it, or c. we don’t have the budget to do it.

In answer to these reasons, I will state the obvious: a. internal users are important too, b. John is too busy to be putting out another fire, and c. (here’s the big one) you are losing money by not monitoring!  Just do it already.

As a long time user of Outlook, I have rarely had problems.  On my main machine (Windows XP SP2, with 2GB memory), I often discover through Task Manager that Outlook’s process outlook.exe is gobbling up huge amounts of memory which can affect my system’s performance. 

Half of the time, I simply ignore the fact that it is consuming over 300MB of memory - yes, that’s 300 of my 2048 MB of memory.  However, there are times when I have at least a dozen programs open and must be vigilant of memory usage or my overall productivity will fail.

To reduce Outlook’s memory usage, I have tried:

1. Reducing the size of the .pst files - works to some degree
2. Moving email messages out of the Inbox and into other folders - helps with the overall performance and startup of Outlook
3. Minimize Outlook, then Maximizing it again, which is recommended by this KB article from Microsoft: http://support.microsoft.com/kb/827310

I’m not overly concerned by its behavior, but, I would like to have a way to control the maximum amount of memory used.

The UK website http://www.vnunet.com/ is truly slow.  Maybe it is slow from my location in the USA, but some of the users on their forums have complained about the slowness of the site way back in 2006. 

There are plenty of external javascript sources which are probably slowing it down. 

Clicking on the “Forum” link at the top of the main navigation, brings the site visitor to the page quickly; however, individual threads in the forums load slowly which could indicate sluggish database performance.

After using the site for a few minutes, all of the sudden, it started to respond very quickly.  If this were my site, I’d worry just a bit.

Log this site under painful.

In HTML, one can reference a file that contains just javascript by using the javascript tag with the src attribute:

<script type=”text/javascript” src=”http://www.server.com/myscript.js”></script>

This can have some benefits with regard to performance, except when the file is located on a different server that you have no control over.  Having more than one of these external javascript links can make matters even worse.

Take example the site Team Sugar.  I stumbled upon this site while doing a blog search for “slow website” on Google.  One person’s post on that site lead me to it and the source pointed out some revealing facts: there are numerous external resources. 

While the site does not take very long to load, it has the potential to slow to a crawl, should one of the external links slow. 

My suggestion?  Add the “defer” attribute to the <javascript> tag and reduce/eliminate the external links.

Visit Team Sugar here:

http://teamsugar.com/1574837

Website performance is a reflection of the efficiency and credibility of your company or organization.  From the most technical power users to people just learning how the Internet works, a slow website is a slow website.

Sometimes the best way to avoid poor website performance is to create a checklist of things NOT to do.

First, here are the quickest and easiest website performance killers:

1. Don’t optimize any images.  Many website images or graphics are un-optimized – reduced in colors or density to ultimately reduce file size.  Even with today’s blazing fast connections to the Internet, slowly loading images are noticeable.  Images over 50KB in size should be optimized. 
2. Create long pages of seemingly endless text and images.  Often seen as helpful to SEO, long web pages can take longer to load and incur more traffic between the web server and a web browser.
3. Avoid cascading style sheets which can reduce page size and load time.  Cascading style sheets also make it easier to create a consistent look-and-feel for your website.
4. Use nested tables – tables within tables – to give the appearance of nothing happening when a web page is loading.
5. Use frames.  Frames are pages within pages that need to load as individual pages.

Next, here are some of the more subtle yet lethal ways to slow your website down:

1. Open database connections but never close them.  Database connections that are not properly closed, can hold on to system resources, i.e. memory, that can eventually lead to the entire server performing slowly or crashing.
2. Don’t optimize database queries by testing them first or by using stored procedures.
3. Use lengthy comments in the HTML code which no one will ever see but will be loaded by the browser.
4. Use java applets for unnecessary animation.  While java applets can be useful, using them for showing a simple animation can be time consuming as the java compiler needs to load.
5. Don’t monitor your website for performance trends of web page response times. Software to monitor website performance is widely available and can pinpoint the best and worst time periods that your website is responding. It can also alert you when your website is not responding at all.