Surfacing - been busy with a large ASP.NET project
I've been pretty silent on my blog lately due to time pressures at work. That's easing up a bit, and I'm very eager to start posting again, about (1) what I've learned on this project, and (2) other things I've been wanting to post about but haven't had time.
I've been busy as the technical lead on a project to redesign a large legacy ASP extranet. As part of the effort, we migrated from ASP to ASP.NET. The previous version of the site used over 20,000 physical files, several VB COM objects (some with source) spanning 7 years, and was mostly written by contractors who have long since departed.
The new version of the site is a pretty advanced CMS driven site that makes heavy use of caching, both at the application and request level. Rob Howard's article in the November MSDN magazine describes these techniques pretty well. We stress tested on Friday against our QA environment - a single machine with dual 733 MHz processors - and it did very well. The production environment uses two machines, each with quad 3.2 Ghz Xeons and 3GB RAM, and I anticipate this app will zip. Heck, a VB3 CGI app should run quickly on servers like that.
The application maintains an in-memory digest of the site hierarchy, as well as enough information that the top three level pages in the site can display without hitting the database. It runs a periodic checksum on some key database tables to determine if the digest is stale - if so, it performs the more expensive site nav reload. The periodic hit takes about .2 seconds, whereas the site nav reload takes 4 - 8 seconds. This all runs in a background thread, managed by an HTTP Module.
We're using a URL rewriting engine based on the regular expression rules config section in Fritz Onion's redirect HTTP Module. It's allowed us to cut the number of physical files serving the content dramatically while maintaining the meaningful URL's the users and content editors are used to. It also helps our search engine software (iPhrase One Step) to auto-categorize based on URL paths.
We implemented a page templating system that anticipates ASP.NET 2.0 Master Pages. Layout templates contain minimal HTML - they mostly serve to position content specific User Controls on the pages. The User Controls know how to render themselves based on their context (the requested URL path).
The combination of URL rewriting and page templating gives us a huge amount of flexibility due to providing two levels of indirection. A requested URL can be mapped to any page, which can implement any template.
We've used an instance object that provides access to all the information about the current request - user information, request information, etc. It's maintained in the HttpContext, and in many cases just points to objects or values in the HttpContext (request level cache), Application ("permanent" storage), Session (lightweight serializable user specific information), and Cache. This has been especially helpful in a way I hadn't anticipated - we can move the actual storage of information between cache, application, context, etc., without affecting dependant code.
I look forward to writing about these different components in more depth over the next few months.