If you are using IHttpHandlers to serve dynamic content, or generating a large directory structure to be served statically, here is some information you should know.
We use a custom IHttpHandler to dynamically serve (and cache) images from our database. For simplicity, the handler uses Request.PhysicalPath as the ultimate cache location. That is, a url “~/cache/123/1-Large.image“ is mapped to “<path to application root>\cache\123\1-Large.jpg“ by the handler. If the file exists, it is served, otherwise it is read from the database, cached to the local file, then served. The '123' directory is created on-demand.
The main advantage of using Request.PhysicalPath is that no configuration parameter is needed to indicate the cache base path. Also it is highly performant on a cache hit.
Recently we ran a utility program called Handle against our production web servers. Handle emits a list of open file/directory handles. We noticed that each directory involved in a request to the image handler had an open file handle! That is, '“<path to application root>\cache\123' is open.
The reason is that ASP.NET sets up a FileMonitor for each directory, to monitor for web.config files should one be created.
We simply stopped using Request.PhysicalPath and turned to mapping the request path to a private cache directory. Since the monitor is only set up for existing directories, so it is safe to use a handler in this way, so long as the underlying 'natural' directory structure is not created.