So now that the site has launched, I can announce that the hybrid solution was for 1.FM.  First off, let me mention that DNN is "heavy."  I hate that it's a website and not a web application.  The build times are incredible.  I'd much rather build locally then upload and have it just work.  Instead, after you upload a file, it reocmpiles the whole application.  With an application as big as 1.FM, this can take a minute or two, even on their new 8-core server with 8GB of RAM!  The one time I thought IIS went down because it took so long.

However, with that said, I still say the benefits of the solution far outweigh the hurdles.  First of all, I get a prepackaged set of modules for purchase at www.snowcovered.com.  Second of all, it gives me a single authentication and authorization system for anything that I wanted to custom build.  Combined, there isn't much I can't dothat would be within 1.FM's needs.

At launch, we were faced with two performance issues that I think are worth mentioning.  The first is something to be ever aware of when using prepackaged software:  just because it looks like it does what you want, doesn't mean it does it well!  Most of the features that are on every page and that deal directly with 1.FM data I built myself and made heavy usage of data caching.  However, when we launched, there was something on the site that was just killing us and more or less bringing the site to a standstill (with about 4100 concurrent users).  After profiling with RedGate's Ants Profiler we found that it was the "latest videos" module on the homepage.  Apaprently it wasn't caching any of its data.  And of course it was the one boxed module I was relying on to be on every page!  We solved the issue by wrapping the module control in our own custom User Control and using OutputCache.  Since there was no need to ever hide videos -- all videos are public all the time -- there was no reason for us not to cache the rendered control itself.

And this brings us to the second issue.  I completely underestimated the power of caching controls!  I was very strict about the way that I cached the data.  Everything was cached and fetched in an application thread, so no user felt the burden of requesting data ever.  However, with 4000 people hitting the site at the same time, just databinding and rendering that data became a HUGE bottleneck.  We were maxing out the 8 CPU cores consistently.  With just a few strategically placed OutputCache's in my user controls (actually I think it only took _three_) we were able to keep the server load at approximately 20-30% CPU usage with that server load, which is more than acceptable.  I have to give all the credit to Phil for this one.  He stepped away from his project of the day to run the profiler and tell me what to look for while I coded away like a good little monkey. He tracked down the problem spots, I put in the cache control, and off we went.

We'll still be doing some maintenance and changes on the site.  I don't know if we're out of the woods just yet with the performance tuning!  But if I have to take one thing away from this it's never underestimate the power of a good profile.

 -eli

Just a quick update.  I had a lot of success implementing the hybrid solution.  I continued to keep my existing C# projects in tact and used post-build events to copy files from my existing C#/ASP.NET projects to the DNN root /Website folder.  I made a few small modifications to the DNN core to allow for some client-specific requirements, but otherwise left DNN alone.

Overally i'm happy with the solution as it stands.  It was a little difficult to work with since I had existing structure that I didn't want to have to re-code (for both time and for cost reasons!).  After this project wraps up, I'm going to try a ground-up approach to see if I can simplify DNN development for regular ASP.NET developers.  DNN offers a lot of infrastructure and modules at your disposal, but the caveat is that you have to be familiar with DNN to use it and expand upon it; my hope is to close that gap and let standard ASP.NET developers do amazing things in DNN... That is, I want to do all of that, if I have the time to build that framework

Cheers
 -eli

Last week I started a DNN/ASP.NET hybrid experiment.  I've worked with DNN in the past, and overall you get quick, easy, CMS solutions, but it feels a bit cookie cutter.  The way the modules are placed into the site often feels really static and "cheap."  The payoff, though, is that you get the support of literally thousands of developers at http://www.snowcovered.comthat all code to the same CMS, meaning you get lots and lots of out-of-the-boxfunctionality for aCMS or social website.

What I'm experimenting with now is whether or not I can mix and match ASP.NET directly with DNN.  Using a simple Control Wrapper module, which takes any given ASCX control and wraps it in a DNN module so you can insert it into a DNN page, I'm making entire controls for the new 1.FM that are essentiallythe "meat" of all the 1.FM pages.  That means I can still have my own custom admin pages and custom controls without having to code directly for DNN, but when I find an out-of-the-box module that I want to use, such as a forum, image gallery, reporting engine, chat room, or anything else, I can immediatley make sure of them.

So far, everything seems to be going smoothly.  I am planning on writing an article on the process once it's done, and I'll post another blog entry when I have my findings, so stay tuned.

 If this works, it could bring on a whole new way for developers to build websites.  No longer will you have to be a DNN Developer to take full advantage of the DNN infrastructure and supporting features.

To be continued.

 -eli