Wednesday, May 23, 2007
There is a discussion over at Scott Hanselman's site about URL Rewriting in ASP.NET.  I found a similar article about URL Rewriting in ASP.NET on Coding Horror


Synopsis:

Here is a brief synopsis of the problem.  In order to have an http module or handler take care of your url rewriting you must have all requests sent to aspnet_isapi.dll via application extension mapping in IIS 6.

Here is an example:

I want http://whatyour20.com/modules/view-location.aspx?locid=1234

to instead look like:

http://whatyour20.com/locations/yellowstone-national-park/

I do this for several reasons.  The number one reason is SEO.  We want google to give google a good idea of what this page is about.  Obviously the latter url does the much better.  It also gives the users an idea of what the link is about.  Number two, it makes our links hackable.  Number 3, it makes our links more aesthetically pleasing.  I think that is very important.  If I see a url that is meant for people instead of machines, I know the web site creator took some time to dot every i and cross every t.  Number four is the less likely option that I will switch technologies and I don't want to lose all my links and there associated page rank if I switch to a new technology or if Microsoft changes thier extension in the future when the next great thing comes out (Silverlight Foundation Server Pages Advanced with SteelRuby, LOL). 

At whatsyour20.com we use UrlRewritingNet.UrlRewrite to handle all url rewriting duties.  UrlRewrite is an asp.net http module that can rewrite any incoming url and it can handle redirects (301, 302).  This works great but it doesn't get rid of the aspx extension by itself.  In fact no http module or handler can do that because iis uses the file extension to determine which program should handle the request. 

So we need to have IIS route all requests for the domain (http://whatsyour20.com) to the aspnet_isapi.dll as stated above.  The problem with this is that now ALL request will go through asp.net.  We may not need this for all requests.  In fact this can be a problem as it can hurt performance.  I've seen the a claim of 30% performance decrease someplace but I don't remember where right now.  However, it's safe to assume that routing static content through asp.net is just not the best solution.

Solution:

The solution?  After the background information we are finally at the payoff.  This is how we get the goodness of using asp.net url rewriting via http modules and the associated debugging and high level of control this brings us WITHOUT the downside of routing static content through asp.net. 

We access all the static content via a sub-domain.  We use static.whatsyour20.com to server all the static content on the site (Right now this is mostly images).  This is very easy to accomplish.  You simply create another web site in IIS, with the path to the same location as your main domain but using the sub domain.  On this domain you DO NOT route the requests to asp.net.  So on this sub domain all content is handled by IIS because it is static.  You could even take that a step farther and put it on a separate server or use another web server that is optimized for static content. 

Our solution works in a share hosting environment because usually you can set up sub domains on shared hosting.  Also you can usually get all requests routed to asp.net if you put in a ticket and simply ask for it.

A nice side effect of using sub domains is improved performance on the client side.  By increasing the number of hostnames (within reason) we can increase the speed at which the page loads.

Here are a few reference articles on multiple domains names to speed up downloads:
http://yuiblog.com/blog/2007/04/11/performance-research-part-4/
http://www.ajaxperformance.com/?p=33
http://www.die.net/musings/page_load_time/

Conclusion:

Using the presented solution we get a urlrewriting solution that is easy to use and configure (all configuration in web.config), transfers easily between hosting providers (again its all provided by asp.net and web.config) and it improves performance.  I'm still looking for any possible downsides.  Please let me know if you know of any.


Wednesday, May 23, 2007 7:29:14 PM (Central Standard Time, UTC-06:00)  #    Comments [1]
 Wednesday, January 03, 2007
How many times has your database servers hard drives filled up and you want to find the culprit?  Probably not many but for me it happens all the time.  Here is a simple command to get a list of all sql server databases and their file size:

use master
go

exec sp_databases
go

Need to find out where the files are on disk?

SELECT [name] [Database], [filename] [File Path]
FROM master..sysdatabases

Wednesday, January 03, 2007 9:34:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, December 27, 2006

If you have been struggling like me to make your sites XHMTL compliant you realize that it’s not an easy task.  Most of the changes are straight forward if you have a validation tool.  I code a lot of sites in Visual Studio 2005 and it will complain like crazy if you have invalid XHTML.  Hence I try not to write invalid XHMTL because I hate errors and warnings and will compulsively try to make my pages as valid as humanly possible.

 

One of the areas where I’ve had the most trouble with this is create bookmarks with anchor tags.  Most of the examples I’ve seen use the name tag on an anchor so that you can link to it using something like http://example.com/test/#somebookmark.  I think this is an underused feature of html as it makes navigation much better and faster, plus it is much easier to link into a page at just the right point with something like this.

 

When using XHTML you should not use the name attribute as it has been deprecated.  Instead you should use the handy id attribute.  The id attribute will work exactly the same way and has the benefit of being compliant.  Plus you get additional validation of making sure each element has a distinct id.  This was a problem with some sites I’ve seen that use name.  I see the same name used all over the place.  This makes linking to the element somewhat difficult and error prone.

 

On a related note, did you know that most modern browsers can link directly to any element that has a valid id attribute?  This is very handy as you want have to include anchor tags all over you html just to get convenient linking.

 

Bad:  <a name="bookmarkid">Test</a>

Better: <a id="bookmarkid">Test</a>

Best: <p id="bookmarkid">the element i actually want bookmarked can be linked to directly</p>

Wednesday, December 27, 2006 1:47:20 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Friday, November 24, 2006
I've got a few machines at home and I want to use Remote Desktop to connect to them when I'm out and about.  Well one is easy enough to set up if it is either directly connected to the internet (possibly a bad idea) or if you have a wireless router with a firewall and other management features (much more secure).  I have the latter and I set up a rule to forward remote desktop traffic on TCP port 3389 to my main desktop.  But I also have a server I would like to get to.  No problem you just need to change the port that Remote Desktop uses in the registry.  Just go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp and find the PortNumber entry and change it to the port you want.  Make sure you edit it as a decimal by choosing the decimal base.

Here is an easy article on setting up multiple machines for Remote Desktop access.

Check out the article for a lot more info.

Friday, November 24, 2006 8:57:20 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
Here's a code tidbit to enable the service broker in SQL Server 2005.  This needs to be running for caching to work in ASP.NET.

IF (SELECT is_broker_enabled
  FROM sys.databases
  WHERE database_id = DB_ID()) = 0
    ALTER DATABASE yourdatabasenamehere
    SET ENABLE_BROKER
    WITH ROLLBACK IMMEDIATE

The if statement checks to see if the broker is already running.  If it is not then it attempts to enable it.  The WITH statement will rollback any other pending transactions that may be blocking this transactions.  This is important because if you run this statement without WITH ROLLBACK IMMEDIATE then it may seem that the batch will not complete.  Again, this is because other transactions or services like SQL Server Agent may be blocking.

Friday, November 24, 2006 8:41:50 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Sunday, November 19, 2006

One argument script pimps use frequently is that it doesn’t matter what tools a contractor uses to build a house as long as the finished product is the same.

The problem with this argument is that the premise and the analogy are flawed.  Comparing the language to the tools is not quite accurate.  The language is more aptly compared to the building materials used instead of the tools.  The tools would instead include things like the IDE.  With the analogy corrected we now see that the choice of building material is very important.  Using 2x4's instead 2x6's will have a big impact on insulation properties (thicker wall cavities) and cost. 

Is this important?  Absolutely!  

Unfortunately, too many scripting language fans (script pimps) make the same flawed analogy in order to justify the use of their pet language instead of a higher performance language like C++ (or C#, Java, etc).  Scripting languages like Ruby are slower then compiled languages.  Also their nature precludes them from having good IDE support.  This is because much of the meaning (context) can’t be derived until runtime so things like IntelliSense become difficult if not impossible to implement. 

Following the scripter’s analysis we are supposed to assume that scripting languages allow faster construction which I would say is another falsehood.  Yes, some contractors might be able to cut wood just as fast with a handsaw but most want to use as much automation as possible.  Hence, table saws, compound miter saws with laser guides, etc.  These automation tools are closer to Visual Studio than VIM. 

In my experience with Ruby (among other languages) I found that the resulting programs were usually slower, which a scripting language will be by its nature.  I also found that the emperor wears no clothes!  Shockingly, developing in a scripting language is slower because of the lack of automation tools.  Example, try to find all references to variable in a Ruby on Rails project.  Now try the same thing in a C# project using Visual Studio.  In Visual Studio it’s a right click and “Find All References”.  In VIM you could search for the references but you don’t have any support for context.  You don’t know that is the only reference to that variable.  You are using a handsaw instead of the best tools available.

I'm sorry but reality demands that 1 = 1 and slower is slower and speed is important.

Sunday, November 19, 2006 9:53:49 AM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Wednesday, November 15, 2006
As you may have noticed, I'm on a performance kick as of late.  Here's one more tip for you.  Compressing / Minimizing / Shrinking your JavaScript files can decrease download times.  Putting your scripts together in one file will also help performance.  Here's a good article on reducing page load times from a Google engineer.  This article is the source for most of this wisdom.

So armed with this new knowledge I went in search of some pre-shrunk versions of the Prototype and Scriptaculous JavaScript Libraries.  This is what I found.  I still need to test the library but it seems promising.  I will keep you posted.

Wednesday, November 15, 2006 11:44:42 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
Ok URL Rewriting is good.  I won't go into the reasons why but if your searching for it then you already know you want it. 

If you followed the standard progression you probably started with this MSDN article on URL Rewriting.  This implementation works fairly well in ASP.NET 1.x.  However, I've run into problems using this implementation in ASP.NET 2.0 with output caching.  For some reason it breaks output caching.

So what is the solution?

Well I'm glad you asked.  I've found a solution that works quite well with ASP.NET 2.0 and output caching.  The UrlRewritingNet.UrlRewrite assembly provides all the features of the original URL Rewriter mentioned above but also fixes the problems with output caching plus adds some interesting features like redirecting and programmatic access to the rewrite rules at runtime (say that ten times fast!). 

I'm currently using this on http://www.whatsyour20.com and I must say it works quite well.  I also like the fact that it is an active project and it even has a bug tracker system.  There is also a forum for this project.  That's always a good sign.

Enjoy!

 |  | 
Wednesday, November 15, 2006 10:20:11 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
What do you do when you want HTTP Compression to speed up your site but you are using ASP.NET (1.x or 2.0) in a hosted environment?

You get HttpCompress from www.blowery.org/code/httpcompressionmodule.html. This is a module that sits inline and handles compression of your .aspx pages and any other mime type that may be handled by ASP.NET.  This is a pretty good work around if you don't have permission to IIS to enable HTTP Compression there.  Of course that would be a better solution but many hosters won't enable it because of the possible CPU consumption issues.  Oh well, get around them by implementing your own solution!

I know dasBlog uses it in the 1.9.x version.  WhatsYour20.com is also using it at this time.

It's been around for awhile, it's configurable and it's easy to use. 

Give it a try and speed up your site today!

One caveat is testing it using ASP.NET Development Server.  Check out the link for more info.

 |  | 
Wednesday, November 15, 2006 10:10:06 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
I've not researched this to find out if all the numbers presented are correct, so for the sake of argument I will assume they are.

This video suggests we are being overrun by immigrants and that our population will sky rocket because of their birth rates.

Now I’m somewhat of the opinion that more people are better because you have more innovation etc, but I also believe we are experiencing some problems from this mass human migration.

I wonder if the pressure on the bottom end of the housing market is driving up prices and that the huge number of new laborers in the job market is keeping wages stagnant.  So we will experience higher costs from housing and other sources as we compete for scarcer resources (oil, natural gas, land) while having less money in real terms.

As a Libertarian where do I stand on this?  As I stated previously I think more people can spur innovation and can be a boon to the economy.  This of course assumes that new immigrants don't require many services from the government which unfortunetaly is not the case in our socialist country.  We provide many services to these people and their dependants.  So in a free society law abiding people should be able to come and go as they see fit.  However when these people expect/require services and violate the law to get here, by definition I have a problem with that. 

I have no problem with admitting an unlimited number of PhD's into this country for instance.  I have a slight problem though admitting an unlimited number of gardeners and meat cutters that will require my assistance because the Left in this country has decided to use the police power of the state to ensure my money can be forcefully taken from me and restributed to the "poor" (poorer then whom?) and "those less fortunate" (less fortunante the whom?). 

So because many of these people will be entitled to the wealth of the current citizens I don't believe the pure Libertarian argument would apply in this situation.

Here is the link, hang in there the beginning is slow but the visuals are worth it ( kind of like an acid trip ;) ):

Visual Demonstration of Immigration to the US


Wednesday, November 15, 2006 4:59:30 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
 Tuesday, November 14, 2006
So if you're having odd issues with a JavaScript function like WebForm_InitCallback(); which is a built in ASP.NET JavaScript function and you are using the HTTP Compression Handler from blowery and you are testing a site on the ASP.NET development server, I may have a fix for you. 

In your web.config you should add an exclude statement to exclude the WebResource.axd path:

        <httpCompress preferredAlgorithm="gzip" compressionLevel="high">
            <excludedMimeTypes>
                <add type="image/jpeg" />
                <add type="image/gif" />
                <add type="image/png" />
            </excludedMimeTypes>
            <excludedPaths>
                <add path="WebResource.axd"/>
            </excludedPaths>
        </httpCompress>


Tuesday, November 14, 2006 4:08:45 PM (Central Standard Time, UTC-06:00)  #    Comments [0]
I just updated from dasBlog 1.8.x to 1.9.x and everything appears to be smooth.  I notice much better performance.  Several reasons could be a changed of hosting plan or that dasBlog now uses HTTP Compression.  Either way I'm happy with the speed up and I'm playing with the new features to see what if any I can use.

Tuesday, November 14, 2006 9:35:06 AM (Central Standard Time, UTC-06:00)  #    Comments [0]