2

I'm setting up a win 2012 / IIS 8 web server with URL Rewrite module installed to replace an existing web server.

It will have 3 heavily used sites on it mapped to different domain names.

  • domain1.com (site 1 in IIS with host name binding to domain1.com)
  • domain2.com (site 2 in IIS with host name binding to domain2.com)
  • domain3.com (site 3 in IIS with host name binding to domain3.com)

The problem I have is that I have many legacy domains (~20) that need to be redirected (301) variously to these sites and external sites.

1) I can use URL Rewrite rules defined at the server level to create these redirects

or

2) I can create an additional site, and use host name binding to bind all these 20 or so names to that site, and then within that site use - URL Rewrite rules

or

3) what else would be more efficient?

I'm kind of leaning towards option 2 because I would guess the site name bindings would be more efficient than evaluating the URL rewrite rules to all incoming requests - and the URL rewrite rules would only be evaluated when a matching host name came in. Looking at the existing logs traffic to the legacy URLs is < 1%

Improve this question
2
  • 1
    IMHO, am with you on #2. Depending on how you want to redirect, how about not involving IIS at all - e.g. URL forwarding at your Registrar or DNS provider (if provided and/or if you are ok with a simple 301 - re: no rebuilding of query strings and such)?
    – EdSF
    Nov 20, 2013 at 21:49
  • my redirect needs are simple enough that I might be able to get away with that - expect that I know my DNS provider (in-house) won't offer me that.
    – bkr
    Nov 20, 2013 at 22:15

1 Answer 1

Reset to default
2

If you go with 1), all your requests (even to the valid site) have to be processed by the url rewrite module. If you have a whole bunch of rules this adds to the processing time of each request.

If you go with 2), just the requests not already handled by the main site are processed by the rewrite module. This is preferable.

A third option would be, to still have 20+ sites. One for each original site. Then for each site you have a much smaller list of rewrite rules just for that specific site.

Even though this option takes longer to set up (scripting is your friend), it should be the fastest, because you let http.sys in kernel mode decide what do to with the each request, it routes the request to the correct site. Then your rewrite rules have less work to do.

Improve this answer
3
  • that is a good point on option 3. I'm going with option 2 for now because the volume of traffic to the old URLs is sufficiently low that keeping my sites list relatively "clean" probably is worth it - although I wonder if there's some performance issues with so many bindings to one site. When I change a URL Rewrite rule defined within that bundled rewrite site IIS does seem to pause for a longer period than normal. I'm in the process of setting up WCAT scripts for load testing so I probably will try under both scenarios to see if anything interesting is visible result wise.
    – bkr
    Nov 23, 2013 at 19:39
  • It could be that additional threading overhead for all those additional sites has a performance impact over any you'd gain for less URL Rewrite parsing but this is not my area of expertise, I suppose testing is the only way I'll find out.
    – bkr
    Nov 23, 2013 at 19:41
  • @bkr - I haven't done any testing between options two and three, it may depend on the number of sites and rules. But IIS is very optimized to handle many (hundreds) sites while the URL rewrite module is just an add-on. Testing is always a good idea.
    – Peter Hahndorf
    Nov 23, 2013 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .