Scott Forsyth's Blog

Why is the IIS default app pool recycle set to 1740 minutes?

Microsoft IIS Server has what appears to be an odd default for the application pool recycle time. It defaults to 1740 minutes, which is exactly 29 hours. I’ve always been a bit curious where that default came from. If you’re like me, you may have wondered too.

Wonder no longer! While at the MVP Summit this year in Bellevue WA I had the privilege again of talking with the IIS team. Wade Hilmo was there too. Somehow in the conversation a discussion about IIS default settings came up, which included the odd 1740 minutes for the app pool recycle interval. Wade told the story of how the setting came into being, and he granted me permission to share.

As you can imagine, many decisions for the large set of products produced by Microsoft come about after a lot of deliberation and research. Others have a geeky and fun origin. This is one of the latter.

The 1740 story

Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.

Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!

That’s a fun little tidbit on the origin of the 1740. How about in your environment though? What is a good default?

Practical guidelines

First off, I think 29 hours is a good default. For a situation where you don’t know the environment, which is the case for a default setting, having a non-resonate pattern greater than one day is a good idea.

However, since you likely know your environment, it’s best to change this. I recommend setting to a fixed time like 4:00am if you’re on the East coast of the US, 1:00am on the West coast, or whatever seems to make sense for your audience when you have the least amount of traffic. Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools it may be wise to stagger them so that you don’t overload the server with a lot of simultaneous recycles.

Note that IIS overlaps the app pool when recycling so there usually isn’t any downtime during a recycle. However, in-memory information (session state, etc) is lost. See this video if you want to learn more about IIS overlapping app pools.

You may ask whether a fixed recycle is even needed. A daily recycle is just a band-aid to freshen IIS in case there is a slight memory leak or anything else that slowly creeps into the worker process. In theory you don’t need a daily recycle unless you have a known problem. I used to recommend that you turn it off completely if you don’t need it. However, I’m leaning more today towards setting it to recycle once per day at an off-peak time as a proactive measure.

My reason is that, first, your site should be able to survive a recycle without too much impact, so recycling daily shouldn’t be a concern. Secondly, I’ve found that even well behaving app pools can eventually have something sneak in over time that impacts the app pool. I’ve seen issues from traffic patterns that cause excessive caching or something odd in the application, and I’ve seen the very rare IIS bug (rare indeed!) that isn’t a problem if recycled daily. Is it a band-aid? Possibly, but if a daily recycle keeps a non-critical issue from bubbling to the top then I believe that it’s a good proactive measure to save a lot of troubleshooting effort on something that probably isn’t important to troubleshoot. However, if you think you have a real issue that is being suppressed by recycling then, by all means, turn off the auto-recycling so that you can track down and resolve your issue. There’s no black and white answer. Only you can make the best decision for your environment.

Idle Time-out

While on the topic of app pool defaults, there is one more that you should change with every new server deployment. The Idle Time-out should be set to 0 unless you are doing bulk hosting where you want to keep the memory footprint per site as low as possible.

If you have a just a few sites on your server and you want them to always load fast then set this to zero. Otherwise, when you have 20 minutes without any traffic then the app pool will terminate so that it can start up again on the next visit. The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. That can take a few seconds. Therefore I set that to 0 every chance I have, unless it’s for a server that hosts a lot of sites that don’t always need to be running.

There are other settings that can be reviewed for each environment but the two aforementioned settings are the two that should be changed almost every time.

Hopefully you enjoyed knowing about the 29 hour default as much as I did, even if just for fun. Happy IISing.

Using WebDAV with ARR

Application Request Routing (ARR) is a great solution for load balancing and other proxying needs. I’m a big fan and have written often about it.

I had someone ask me this week about WebDAV support for ARR. With his ARR setup, he noted that WebDAV creation, uploads, and downloads worked well, but renaming and moving files did not. He aptly noticed in the IIS logs that the source IP address showed as being from the ARR server rather than from the original user.

Here’s what the IIS log recorded:

2013-01-28 10:36:20 10.11.12.13 MOVE /Documents/test https://domain.com/Documents/test 80 User 10.9.8.7 Microsoft-WebDAV-MiniRedir/6.1.7601 400 1 0 31

So for anyone working with WebDAV and ARR and it doesn’t work for you, it’s likely that ARRHelper needs to be installed on the web servers.

You can find ARRHelper here, and if interested, I have a short video explaining what it is and why it’s important.

Handing MVC paths with dots in the path

A friend of mine asked me recently how to handle a situation with a dot (.) in the path for an MVC project.  The path looked something like this:

http://domain.com/aspnet/CLR4.0

The MVC routes didn’t work for this path and the standard IIS 404 handler served up the page instead. However, the following URL did work:

http://domain.com/aspnet/CLR4.0/

The only difference is the trailing slash. For anyone that runs into the same situation, here’s the reason and the solution.

What causes this inconsistency

The issue with the first path is that IIS can’t tell if the path is a file or folder. In fact, it looks so much like a file with an extension of .0 then that’s what IIS assumes that it is. However, the second path is fine because the trailing slash makes it obvious that it’s a folder.

We can’t just assign a wildcard handler to MVC in IIS for all file types because that will break files like .css, .js, .png, and other files are processed as static images.

Note that this would not be an issue if the dot is in a different part of the path. It’s only an issue if the dot is in the last section. For example, the following would be fine:

http://domain.com/aspnet/CLR4.0/info

So how do we resolve it?

As I mentioned, we can’t simply set a wildcard handler on it because it will break other necessary static files. So have about three options:

1. You could always change the paths in your application. If you’re early enough in the development cycle that may be an option for you.
2. Add file handlers for all extension types that you may have. For example, add a handler for .0, another for .1, etc.
3. Use a URL rewriter like IIS URL Rewrite to watch for a particular pattern and append the training slash.

Let’s look at these second two options. I’ll mention now up front that the URL Rewrite solution is probably the best bet, although I’ll cover both in case you prefer the handler method.

Http Handler Solution

You can handle specific extensions by adding a handler for each possible extension that you’ll support. This maps to System.Web.UI.PageHandlerFactory so that ASP.NET MVC has a handle on it and you can create an MVC route for it. This would apply to ASP.NET, PHP, or other frameworks too.

C:\Windows\System32\inetsrv\appcmd.exe set config "Sitename" -section:system.webServer/handlers /+"[name='.0-PageHandlerFactory-Integrated-4.0',path='*.0',verb='GET,HEAD,POST,DEBUG',type='System.Web.UI.PageHandlerFactory',preCondition='integratedMode']" /commit:apphost
C:\Windows\System32\inetsrv\appcmd.exe set config "SiteName" -section:system.webServer/handlers /+"[name='.1-PageHandlerFactory-Integrated-4.0',path='*.1',verb='GET,HEAD,POST,DEBUG',type='System.Web.UI.PageHandlerFactory',preCondition='integratedMode']" /commit:apphost

Run this appcmd command from the command prompt to create the handlers.

Make sure to update “Sitename” with your own site name, or leave it off to make it a server-wide change. And you can update ‘*.0’, ‘*.1’ to your extensions.

If you do create the site-level rule, make sure to save your web.config back to your source control so that you don’t overwrite it on your next site update.

IIS URL Rewrite Solution

Probably the best solution, and the one that my friend used in this case, is to use URL Rewrite to add a trailing slash when needed. The advantage of this is that you can use a more general pattern to redirect the URL rather than a bunch of handlers for each specific extension.

This assumes that you have IIS 7.0 or greater and that you have URL Rewrite installed. If you’re not familiar with URL Rewrite, check out the URL Rewrite articles on my blog (start with this one).

Note: If you want, you can skip this section and jump right to the next section for an easier way to do this using URL Rewrite’s rule wizard.

The following rule watches for a pattern of exactly “something.{digits}” (without a trailing slash). If it finds it then it performs a redirect and appends the trailing slash. It also confirms that it’s not a file or directory that exists on disk.

<rule name="Add trailing slash for some URLs" stopProcessing="true">
    <match url="^(.*\.(\d)+)$" />
    <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
    </conditions>
    <action type="Redirect" url="{R:1}/" />
</rule>

To apply this rule, using IIS Manager you can create a dummy rule as a placeholder and then edit web.config and replace your placeholder rule with this rule. If this still doesn’t make sense then be sure to review the articles I mentioned above. The configuration location is in <configuration><system.webServer><rules><rule>…

An added benefit of this rule is that you’ll make the search engines happy by having just one path for each page, rather than possibly two with and without the slash. This will help with your SEO rankings.

I didn’t think of it at the time but just now I realized that you could use a general match url pattern of “.(*[^/])” and it will work for you too. The reason is that the check for IsFile and IsDirectory will ensure that your static images will continue to be served directly from disk so you won’t break them. So feel free to use <match url="(.*[^/])" /> instead if you want to add the trailing slash for all paths that don’t have them.

The Real Easy Solution (URL Rewrite wizard)

In fact, to make this easier yet, you can use URL Rewrite’s existing rule wizard to add the trailing slash. You must apply this at the site or folder level since the trailing slash wizard doesn’t exist at the server level.

1. From IIS Manager, open URL Rewrite at the site or folder level.
   
2. Click “Add Rule(s)…” from the Actions pane.
   
3. Select “Append or remove the trailing slash symbol” rule.
   
4. Use the default option of “Appended if it does not exist”
5. Press OK.

That’s it! You’ll have a rule added which will append the trailing slash for all non-physical file or folder paths that don’t already have the trailing slash. Not only will it handle dots in the path but the search engines will be happy too.

As with the http extension solution, if you create this as a site or folder-level rule, it will be applied to your web.config file. Make sure to update web.config in your source control so that you don’t lose your changes on your next site deployment.

Windows 8 / IIS 8 Concurrent Requests Limit

IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.

However, the client version of IIS 8, which is on Windows 8, does have a concurrent connection request limitation to limit high traffic production uses on a client edition of Windows.

Starting with IIS 7 (Windows Vista), the behavior changed from previous versions.  In previous client versions of IIS, excess requests would throw a 403.9 error message (Access Forbidden: Too many users are connected.).  Instead, Windows Vista, 7 and 8 queue excessive requests so that they will be handled gracefully, although there is a maximum number of requests that will be processed simultaneously.

Thomas Deml provided a concurrent request chart for Windows Vista many years ago, but I have been unable to find an equivalent chart for Windows 8 so I asked Wade Hilmo from the IIS team what the limits are.  Since this is controlled not by the IIS team itself but rather from the Windows licensing team, he asked around and found the authoritative answer, which I’ll provide below.

Windows 8 – IIS 8 Concurrent Requests Limit

Windows 7 – IIS 7.5 Concurrent Requests Limit

Windows Vista – IIS 7 Concurrent Requests Limit

Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 allow an unlimited amount of simultaneously requests.

URL Rewrite – Protocol (http/https) in the Action

IIS URL Rewrite supports server variables for pretty much every part of the URL and http header. However, there is one commonly used server variable that isn’t readily available.  That’s the protocol—HTTP or HTTPS.

You can easily check if a page request uses HTTP or HTTPS, but that only works in the conditions part of the rule.  There isn’t a variable available to dynamically set the protocol in the action part of the rule.  What I wish is that there would be a variable like {HTTP_PROTOCOL} which would have a value of ‘HTTP’ or ‘HTTPS’.  There is a server variable called {HTTPS}, but the values of ‘on’ and ‘off’ aren’t practical in the action.  You can also use {SERVER_PORT} or {SERVER_PORT_SECURE}, but again, they aren’t useful in the action.

Let me illustrate.  The following rule will redirect traffic for http(s)://localtest.me/ to http://www.localtest.me/.

<rule name="Redirect to www">

  <match url="(.*)" />

  <conditions>

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="http://www.localtest.me/{R:1}" />

</rule>

The problem is that it forces the request to HTTP even if the original request was for HTTPS.

Interestingly enough, I planned to blog about this topic this week when I noticed in my twitter feed yesterday that Jeff Graves, a former colleague of mine, just wrote an excellent blog post about this very topic.  He beat me to the punch by just a couple days.  However, I figured I would still write my blog post on this topic.  While his solution is a excellent one, I personally handle this another way most of the time.  Plus, it’s a commonly asked question that isn’t documented well enough on the web yet, so having another article on the web won’t hurt.

I can think of four different ways to handle this, and depending on your situation you may lean towards any of the four.  Don’t let the choices overwhelm you though.  Let’s keep it simple, Option 1 is what I use most of the time, Option 2 is what Jeff proposed and is the safest option, and Option 3 and Option 4 need only be considered if you have a more unique situation.  All four options will work for most situations.

Option 1 – CACHE_URL, single rule

There is a server variable that has the protocol in it; {CACHE_URL}.  This server variable contains the entire URL string (e.g. http://www.localtest.me:80/info.aspx?id=5)  All we need to do is extract the HTTP or HTTPS and we’ll be set. This tends to be my preferred way to handle this situation.

Indeed, Jeff did briefly mention this in his blog post:

… you could use a condition on the CACHE_URL variable and a back reference in the rewritten URL. The problem there is that you then need to match all of the conditions which could be a problem if your rule depends on a logical “or” match for conditions.

Thus the problem.  If you have multiple conditions set to “Match Any” rather than “Match All” then this option won’t work.  However, I find that 95% of all rules that I write use “Match All” and therefore, being the lazy administrator that I am I like this simple solution that only requires adding a single condition to a rule.  The caveat is that if you use “Match Any” then you must consider one of the next two options.

Enough with the preamble.  Here’s how it works.  Add a condition that checks for {CACHE_URL} with a pattern of “^(.+)://” like so:

How you have a back-reference to the part before the ://, which is our treasured HTTP or HTTPS.  In URL Rewrite 2.0 or greater you can check the “Track capture groups across conditions”, make that condition the first condition, and you have yourself a back-reference of {C:1}.

The “Redirect to www” example with support for maintaining the protocol, will become:

<rule name="Redirect to www" stopProcessing="true">

  <match url="(.*)" />

  <conditions trackAllCaptures="true">

    <add input="{CACHE_URL}" pattern="^(.+)://" />

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="{C:1}://www.localtest.me/{R:1}" />

</rule>

It’s not as easy as it would be if Microsoft gave us a built-in {HTTP_PROTOCOL} variable, but it’s pretty close.

I also like this option since I often create rule examples for other people and this type of rule is portable since it’s self-contained within a single rule.

Option 2 – Using a Rewrite Map

For a safer rule that works for both “Match Any” and “Match All” situations, you can use the Rewrite Map solution that Jeff proposed.  It’s a perfectly good solution with the only drawback being the ever so slight extra effort to set it up since you need to create a rewrite map before you create the rule.  In other words, if you choose to use this as your sole method of handling the protocol, you’ll be safe.

After you create a Rewrite Map called MapProtocol, you can use “{MapProtocol:{HTTPS}}” for the protocol within any rule action.  Following is an example using a Rewrite Map.

<rewrite>

  <rules>

    <rule name="Redirect to www" stopProcessing="true">

      <match url="(.*)" />

      <conditions trackAllCaptures="false">

        <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

      </conditions>

      <action type="Redirect" 

        url="{MapProtocol:{HTTPS}}://www.localtest.me/{R:1}" />

    </rule>

  </rules>

  <rewriteMaps>

    <rewriteMap name="MapProtocol">

      <add key="on" value="https" />

      <add key="off" value="http" />

    </rewriteMap>

  </rewriteMaps>

</rewrite>

Option 3 – CACHE_URL, Multi-rule

If you have many rules that will use the protocol, you can create your own server variable which can be used in subsequent rules. This option is no easier to set up than Option 2 above, but you can use it if you prefer the easier to remember syntax of {HTTP_PROTOCOL} vs. {MapProtocol:{HTTPS}}.

The potential issue with this rule is that if you don’t have access to the server level (e.g. in a shared environment) then you cannot set server variables without permission.

First, create a rule and place it at the top of the set of rules.  You can create this at the server, site or subfolder level.  However, if you create it at the site or subfolder level then the HTTP_PROTOCOL server variable needs to be approved at the server level.  This can be achieved in IIS Manager by navigating to URL Rewrite at the server level, clicking on “View Server Variables” from the Actions pane, and added HTTP_PROTOCOL. If you create the rule at the server level then this step is not necessary. 

Following is an example of the first rule to create the HTTP_PROTOCOL and then a rule that uses it.  The Create HTTP_PROTOCOL rule only needs to be created once on the server.

<rule name="Create HTTP_PROTOCOL">

  <match url=".*" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{CACHE_URL}" pattern="^(.+)://" />

  </conditions>

  <serverVariables>

    <set name="HTTP_PROTOCOL" value="{C:1}" />

  </serverVariables>

  <action type="None" />

</rule>

<rule name="Redirect to www" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="{HTTP_PROTOCOL}://www.localtest.me/{R:1}" />

</rule>

Option 4 – Multi-rule

Just to be complete I’ll include an example of how to achieve the same thing with multiple rules. I don’t see any reason to use it over the previous examples, but I’ll include an example anyway.  Note that it will only work with the “Match All” setting for the conditions.

<rule name="Redirect to www - http" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

    <add input="{HTTPS}" pattern="off" />

  </conditions>

  <action type="Redirect" url="http://www.localtest.me/{R:1}" />

</rule>

<rule name="Redirect to www - https" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

    <add input="{HTTPS}" pattern="on" />

  </conditions>

  <action type="Redirect" url="https://www.localtest.me/{R:1}" />

</rule>

Conclusion

Above are four working examples of methods to call the protocol (HTTP or HTTPS) from the action of a URL Rewrite rule.  You can use whichever method you most prefer.  I’ve listed them in the order that I favor them, although I could see some people preferring Option 2 as their first choice.  In any of the cases, hopefully you can use this as a reference for when you need to use the protocol in the rule’s action when writing your URL Rewrite rules.

Further information:

• Viewing all Server Variable for a site.
• URL Parts available to URL Rewrite Rules
• Further URL Rewrite articles

Reading a memory.dmp or other .dmp file

While the dreaded Blue Screen of Death (BSOD) occurs less frequently with newer versions of Windows than it did in years past, there are still times when the BSOD reveals itself. 

I just ran into four BSOD’s on two Windows Server 2012 machines and I had the ‘opportunity’ to analyze a memory.dmp file today, so I thought I would post quick instructions on how to get a handy summary of the memory dump.

I’ve had this ”I Found a Fix” debugging page bookmarked for years and I’ve used it many times, so I need to give full credit to ifoundafix for their helpful steps.  The only change I have below is to include updated paths.

It’s possible to debug remotely, and you may have requirements to do that.  My quick instructions here are for local debugging.  The debugging tools are very stable and if you install just what you need then they are small and a quick install, so running this on a production machine is generally safe, but you must make that decision for your particular environment.

This can be accomplished with 7 easy steps:

Step 1. Obtain and install the debugging tools.  The links do change over time, but the following link is currently an exhaustive page which includes Windows Server 2012 and Windows 8 Consumer debugger tools, Windows 7, Vista, XP and Windows Server 2003.

Debugging Tools Windows

All you need to install is the “Debugging Tools for Windows”.  Everything else is used for more advanced troubleshooting or development, and isn’t needed here.  Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.

Step 2. From the command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\.  You can specify the path during the install.

Step 3. Type the following:

kd –z C:\Windows\memory.dmp (or the path to your .dmp file)

Step 4. Type the following:

.logopen c:\debuglog.txt

Step 5. Type the following:

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Step 6. Type the following:

.reload;!analyze -v;r;kv;lmnt;.logclose;q

Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor.  Searching for PROCESS_NAME: will show which process had the fault.  You can use the process name and other information from the dump to find clues and find answers in a web search.  Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.

Often time a driver update will fix the issue.  If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft.  The steps above will provide you with a summary mostly-human-readable report from the dump.  There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.

Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.

Last Day With OrcsWeb

It’s hard to believe that it’s been 10 years since my first day at OrcsWeb. Today is my last official day, but I’ll still be close by. I have a number of ties here, including being a customer through Vaasnet.

So much has changed in this time. Ten years ago I began working for OrcsWeb from Canada. Nine years ago I moved my family down here to North Carolina and assumed the role of Director of Technology.  I was able to be a part of the company as it grew in staff, servers, customers, and reputation. I feel honored to be a part of OrcsWeb during these exciting years.

During my time at OrcsWeb I have been given opportunities to attend conferences, meet and become friends with top technical experts in the field, write articles, co-author two books, and speak at conferences and code camps. It was through OrcsWeb that I was given opportunities to be active in the community, to become a Microsoft MVP and an ASPInsider.

I’m grateful to Brad and Karla Kingsley who have always treated me like more than an employee. They have always encouraged me to grow and to pursue my dreams.

I’m thankful to Jeff Graves who has been accommodating to my evolving schedule and less than full time availability.  And in terms of technical smarts, Jeff tops the list!  And I’m also thankful of the rest of the team at OrcsWeb who are experts in the field, and with whom it’s always been a privilege to work.

Moving forward, I have two main focuses. I’ll be able to spend more time on Vaasnet (a company I co-founded with Jeff Widmer) to see the company position itself further in the market and to strengthen both the product and the brand.  Additionally, I’m working in a part time basis with Dynamicweb an established CMS and eCommerce company in Europe who is just moving into the US market. Dynamicweb has a strong product already and I’m excited to work with the leadership team in the US. Expect to see more of Dynamicweb in the coming months and years.

I just want to reiterate a big thanks to OrcsWeb for helping write such an important chapter in my life. And it’s with excitement that I look forward to the next chapter of my life.

Introducing Testing Domain - localtest.me

Save this URL, memorize it, write it on a sticky note, tweet it, tell your colleagues about it! 

localtest.me (http://localtest.me)

and

*.localtest.me (http://something.localtest.me)

If you do any testing on your local system you’ve probably created hosts file entries (c:\windows\system32\drivers\etc\hosts) for different testing domains and had them point back to 127.0.0.1.  This works great but it requires just a bit of extra effort.

This localtest.me trick is so obvious, so simple, and yet so powerful.  I wouldn’t be surprised if there are other domain names like this out there, but I haven’t run across them yet so I just ordered the domain name localtest.me which I’ll keep available for the internet community to use.

Here’s how it works. The entire domain name localtest.me—and all wildcard entries—point to 127.0.0.1.  So without any changes to your host file you can immediate start testing with a local URL.

Examples:

http://localtest.me
http://newyork.localtest.me
http://mysite.localtest.me
http://redirecttest.localtest.me
http://sub1.sub2.sub3.localtest.me

You name it, just use any *.localtest.me URL that you dream up and it will work for testing on your local system.

This was inspired by a trick that Imar Spaanjaars introduced me to. He created a loopback wildcard URL with his company domain name.  I took this one step further and ordered a domain name just for this purpose.

I would have liked to order localhost.com or localhost.me but those domain names were taken. So to help you remember, just remember that it’s ‘localtest’ and not ‘localhost’, and it’s ‘.me’ rather than ‘.com’.

I can’t track usage since the domain name resolves to 127.0.0.1 and never passes through my servers, so this is just a public tool which I’ll give to the community. I hope it gets used. And, since I can’t really use the domain name to explain itself, please spread the word and tell others about it.

Some examples on how to use it would include:

• Creating websites on your dev machine.  site1.localtest.me, site2.localtest.me, site3.localtest.me.
• Great for URL Rewrite (IIS) or mod_rewrite (Apache) testing: redirect.localtest.me, failuretest.localtest.me, subdomain.localtest.me, city1.localtest.me.
• Any testing on your local system where a friendly URL would be useful.

I hope you enjoy!

Google and Geo-location, CNDs, DNS Load Balancing-Week 50

You can find this week’s video here.

This week answers two Q&A questions from viewers. DNS Load Balancing and then some discussion and a walkthrough using Application Request Routing (ARR) for a Content Delivery Network (CDN).

There’s a growing movement towards Content Delivery Networks (CDN); fronting web farms and geographically dispersing websites. This week I continue with Q&A’s from viewers, taking questions on DNS Load Balancing and CDNs.

Question 1:

I would love to see some clever DNS load balancing (not sure what capability windows is offering). Flesik

Question 2a:

I would love to see an end-2-end CDN redundant network setup (dns balancing, ARR nodes, parent notes etc). Flesik

Question 2b:

I would be interested in seeing a series on building an ecdn or ecn using ARR and what the best practices would be to scale it out geographically.

It seems ARR is sold that way... really not sold but talked about. I have tried to put my theory out and try it but i just don't know the best way to route my clients to their designated locations. Can you help out with an awesome weblog maybe? Adam

The following URL is the one I mentioned in the video: http://learn.iis.net/page.aspx/649/deploying-application-request-routing-in-cdn

In this week’s video we look at DNS load balancing and geo-location issues that Google faces by using DNS to determine a user’s location. We also take a look at using Microsoft Application Request Routing (ARR) to create a CDN.

This is week 50 of a 52 week series for the web pro. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

What’s new in IIS8, Perf, Indexing Service-Week 49

You can find this week’s video here.

This week I'm taking Q&A from viewers, starting with what's new in IIS8, a question on enable32BitAppOnWin64, performance settings for asp.net, the ARR Helper, and Indexing Services.

This week we look at five topics.

Pre-topic:

Question 1:

In a number of places (http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/, http://channel9.msdn.com/Events/MIX/MIX08/T06), I've saw that enable32BitAppOnWin64 is recommended for performance reasons. I'm guessing it has to do with memory usage... but I never could find detailed explanation on why this is recommended (even Microsoft books are vague on this topic - they just say - do it, but provide no reason why it should be done). Do you have any insight into this? (Predrag Tomasevic)

Question 2:

Do you have any recommendations on modifying aspnet.config and machine.config to deliver better performance when it comes to "high number of concurrent connections"? I've implemented recommendations for modifying machine.config from this article (http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx - ASP.NET Process Configuration Optimization section)... but I would gladly listen to more recommendations if you have them. (Predrag Tomasevic)

Question 3:

Could you share more of your experience with ARR Helper? I'm specifically interested in configuring ARR Helper (for example - how to only accept only X-Forwards-For from certain IPs (proxies you trust)). (Predrag Tomasevic)

Question 4:

What is the replacement for indexing service to use in coding web search pages on a Windows 2008R2 server? (Susan Williams)

Here’s the link that was mentioned: http://technet.microsoft.com/en-us/library/ee692804.aspx

This is now week 49 of a 52 week series for the web pro. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.