I get a few messages about how the rights system fires many times per request and it is a lot of SQL traffic.  Allow me to address this issue and introduce to your silent partner Cassini.

Most developers, myself included, love being able to click the "play" icon (press F5 or select start debugging from the menu) and be able to debug their WebForms or MVC application on their local box. 

The catch here is this- the site you are debugging is not running on/being served by IIS.  It's Cassini. 

Ok now do not jump up and say yes served by IIS...  I am talking about the default configuration that unless you have changed, it is running on Cassini.  That little web page down in the icon tray that says ASP.NET Development Server - Port #### when you mouse over it...that is Cassini. 

I know, "big deal it just serves the application."  What is often over looked is Cassini is not IIS and it behaves very differently.  I am going to talk in some generalities here and gloss over certain details but my good friend Google is more than happy to help fill in the gaps.  IIS handles all web requests through ISAPI filters, one of these filters is the asp.net filter.  The filters sort out who gets to handle each file request.  So by default on IIS; only apsx, .config, ascx etc etc files are handled by the asp.net framework.

Cassini is IIS's dog who ate a cracker with a mound of peanut butter on top of it.  Every request that Cassini gets is handled by the asp.net framework and Cassini just keeps chomping away at it.

Here is where this difference comes into play.  Lets say your site's home page has a 3 js files, 2 style sheets (one of general media and one for print), a logo image, a background image, an image used as li bullets, 4 images that are part of the navigation and another 4 images that are part of the sites design/layout.  Not an unreasonable page makeup right? 

IIS and Cassini both get the request for the aspx page, sends it to asp.net to get the html and sends it back to the client. The client browser see's all of the images, scripts and css files and issues requests to get each file.

IIS gets each request and sends the requests to filters based on the file type requested, in the example we talked about none of them are the asp.net filter.  So you get 1 request to asp.net for the page itself (you may get more because of webresources.axd but we will ignore those....glossing over)

Cassini, still trying to get the peanut butter off the roof of it's mouth, gets every request and, not having filters, passes all of them to asp.net for processing...all of them.  3 js + 2 css + logo + background +li image + 4 navigation + other 4 images....16 additional files for a total of 17 requests that generate an IPrincipal and rights.  Oh, and yes, you still get those other webresource.axd requests. 

If you really want a shock open SQL Profiler and watch the asp.net membership and roles system at work in Cassini. 

How do you fix this?  Well, strictly speaking you can not "fix" it.  By design an HttpModule gets called for every request so it will always get called.  But, you can try to cut down on the sql overhead by modifying your HttpModule to look at the file extension and not do anything for certain file types.  The downside to this is if someone changes the IIS configuration to pass jpg files to asp.net and tries to secure a directory of images in the web.config the Principle may not be correct for it work until you edit the code (you could but the file extensions in an appsetting so it would require modifying the web.config instead of a code change.)

You can suffer with (or ignore) it in Cassini and test performance on a real IIS server...(which we all do anyway's right?)

Or you can use a SqlDependency object or caching in the provider layer or serve back recently cached objects.  Even if you do this, the default asp.net membership and roles is going to kick your SQL Servers butt (Really try SQL Profiler on your database and watch it...)

This is a spot where you need to figure out where you want to eat the cycles of doing it.  If SQL is local to the the web server the memory hit with caching may out weigh the SQL processing costs.  If the SQL Server is over a WAN cache it!   If the SQL Server is on the same switch/network there are lots of factors you will want to look at....bandwidth, throughput, cost of development...etc etc.

However this difference between IIS and Cassini raises it's ugly head in other areas of development as well.  For example, I wrote a HttpModule to stop bandwidth leeching once.  It worked fine on my local PC but failed to work when deployed in the production environment.  Because Cassini passed image requests to ASP.net it worked fine in development; but IIS does not pass them to asp.net so the module never had any requests come in to process.  After altering the IIS configuration to pass images files to the asp.net dll it worked wonderfully.

One other place I have seen Cassini/IIS differences break things was with a large/bulk file uploader that provided a status bar in the browser.  It hooked into a "worker process" class for the web server to pull/write some information.  The problem was Cassini and IIS used different worker process classes and the method being used did not work with Cassini.  For the same reason it did not work on a newer version IIS.  Which means, not all version of IIS behave exactly the same under the hood and if you "hack" something in to get things to work, well....yeah.  It might not work after some random update/SP.

I do development/testing with Cassini, I deploy to my local IIS where I test again; and finally I publish to the production server. When I need to debug HttpModules I set a conditional break that checks the file information so I am not stopping when I do not need to be.

The short of it is, Cassini is not as smart as IIS and it processes files as asp.net request causing extra traffic in your code when you are debugging.  It is too busy with peanut butter to learn about filtering what requests are for ASP.net and which are not.

Cassini on Wikipedia: http://en.wikipedia.org/wiki/UltiDev_Cassini_Web_Server

Special thanks to JB for reminding me to post this article that has been on my flash drive for a long time.