This week I cover a couple ways to obtain information about a specific server in a web farm. How can you tell which node handled your page request? Often it’s valuable to know which node is currently being served for troubleshooting the load balancer or individual pages.
I posted another non-video blog post this morning that covers this same topic and provides the download link to SiteServerDetails.
This is week 13 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Today’s video walks through this HTTP Handler and how you can install it on your web farm. Just now I realized that I forgot to mention how to roll this out on a full web farm with multiple nodes (the target install situation).
The install won’t break anything, even if you install it while shared configuration is enabled. Simply run the quick install on each node of the web farm and it will install without any impact to the production environment.
Having problems viewing on your mobile device? Click here instead.
Often times if you administer a web farm, or develop for a web farm, you want to know which node you’re currently on. This is useful is you want to know if your load balancers are balancing with the algorithm that you expect, or if you want to troubleshoot why a website fails just some of the time.
Note: Rather than reading this blog post, you can learn about the tool and the install from this video blog post instead.
A couple years ago I blogged about an easy way to include the node information on a page. You may include it as an HTML comment, or in a separate page, or temporarily include it on the page during development.
A while back I wrote a simple Http Module that I use for many sites that I administer. It display similar information and can be called at any time to get details on the server node and the site. I wanted to make it available here.
Basically it registers as an HTTP Handler in IIS 6 or 7.x at the server level so that when you call www.yoursite.com/siteserverdetails.axd, it displays the server node that you are on along with the IIS site name.
I find that the IIS site name is useful because I often maintain different instances of the sites that I swap out during deployment. (I’ll cover site instances in more depth later this year).
The download has a tiny file call SiteServerDetails.dll which needs to be registered in the GAC, and a file called install.bat, which I’m sure you can guess what it does. It’s an installer for IIS7.x only. If you want to install on IIS6, just review install.bat to see which steps were taken.
Install.bat has been tested “on my machine” so I can’t promise that it will work on all servers, but it’s simple and straight forward, and it doesn’t hurt to run it multiple times. If something is already installed, it will just provide a message that it was already copied or registered.
To install on all nodes in your webfarm, you don’t need to take it out of shared configuration. Just run the install on each node. It will copy the file and register in the GAC on each node, but only add to applicationHost.config once. And since it’s a http handler for a specific path (siteserverdetails.axd), it won’t affect the production site while you’re rolling it out.
After it’s installed, just visit www.yoursite.com/siteserverdetails.axd and voilà, you’ll have server and site information available to you.
The nice thing about a HTTP Handler is that it’s only called if you call the specific path—in this case siteserverdetails.axd—so this is safe and doesn’t have any overhead for the operation of your website.
Note, this does provide some information that anyone can view if they figure out the URL, so if you feel that this is too revealing, you can password protect it using standard .NET forms authentication. You will need to password protect it for every site, so you can either do so on every site, or else register SiteServeDetails only on the sites that you need it on.
One caveat is that this works with ASP.NET v2.0 and greater. If you still have a v1.1 site (I feel for you) then this will not work. It won’t hurt the rest of the site to have it installed, it just won’t load correctly.
Next week I’ll make another tool available that works with URL Rewrite (in IIS 7.x only) that adds an X-Header to the HTTP response so that tools like Firebug and Fiddler can view similar information on every file, including images.
Download: http://weblogs.asp.net/blogs/owscott/siteserverdetails.zip
AppDomains are a silent mysterious part of ASP.NET and IIS. It’s important for the web administrator to be aware of this building block of ASP.NET so that we can be aware of how changes to the system can affect production sites.
While this series is targeted at the IIS and web administrator, this topic is useful for the ASP.NET programmer too.
This is week 12 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Having problems viewing on your mobile device? Click here instead.
This 2nd part (out of 2) on Regular Expressions covers the remaining tips necessary to get up to speed on a topic that at first seems daunting, but really isn’t that bad.
Whether you use Regular Expressions for URL Rewrite, Visual Studio, PowerShell, programming or any other tool, these tips will allow you to understand the essentials of Regular Expressions.
Be sure to watch Part 1 first.
This is week 11 of a 52 week series on various web administration related tasks. Past and future videos can be found here.
Regular Expressions can seem difficult to understand. In today’s lesson I attempt to bring this down to earth and make it understandable and useful for the web administrator.
While this focuses on URL Rewrite, this lesson is useful for Visual Studio, ASP.NET development and JavaScript development also.
I couldn’t keep this within 10-15 minutes so this is Part 1 of 2 on Regular Expressions. Part 2 can be found here.
This is week 10 of a 52 week series on various web administration related tasks. Past and future videos can be found here.