Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Why was Subtext selected for (a.k.a. Building, part 1)

In my previous post, I mentioned how my new blog is currently powered by Subtext -- or rather my own (slightly modified) version of Subtext 2.5. I also noted that Subtext wasn't my first choice when selecting a blogging solution for the new site.

BlogEngine.NET or dasBlog?

Actually, I started out using BlogEngine.NET. Initially, I looked at both dasBlog and BlogEngine.NET. dasBlog made the short list because I've seen it in use on Scott Hanselman's blog for a number of years and he seems quite happy with the performance, stability, and feature set. He even contributes an occasional bug fix for dasBlog every now and then (e.g. changesets 55621 and 50527) which gave me a "warm and fuzzy" feeling during the due diligence process of selecting a blogging solution.

The problem with dasBlog is that it appears to be "dead" from a development perspective -- meaning nobody seems to be actively working on it. If you look at the main dasBlog site ( you will see that it still refers to the March 16th 2009 version as the latest release -- and yet when you look at the corresponding CodePlex project, you can see dozens of bug fixes and enhancements have been checked in since that time. Therefore I turned my attention from dasBlog and started focusing on BlogEngine.NET instead.

I really liked what I saw in BlogEngine.NET. The solution is very "polished" (unlike a number of other open source blogging solutions out there), appears to be very extensible, and -- unlike dasBlog -- is actively being worked on by the development team. It supports all of the core features that I considered "must haves" for the blog, and it was very easy to install and configure. It also supports BlogML for importing posts (which was originally a "nice-to-have" on my list -- although, in retrospect, I would now consider this a "must have" instead).

Consequently, I decided to go with BlogEngine.NET and proceeded to create a utility to migrate my blog content from my old MSDN blog. That's when I discovered a showstopper...

After migrating the roughly 300 posts from my MSDN blog (running on the Telligent Community platform) into my new BlogEngine.NET-based blog, I noticed some significant performance issues.

Note that the default configuration of BlogEngine.NET does not require a SQL Server database. Instead blog posts are stored as individual XML files and accessed through a provider that encapsulates the underlying storage mechanism.

Suspecting the XML storage implementation to be the source of the performance problem, I spent a few minutes creating a SQL Server database and switching from the XmlBlogProvider to the DbBlogProvider -- and subsequently migrated my historical content into the database. I fully expected this to resolve the scalability issue I discovered shortly before.

Unfortunately it did not.

After spending about a half hour walking through BlogEngine.NET in the debugger, I discovered that the source of the problem was not in the underlying blog provider (i.e. XmlBlogProvider or DbBlogProvider), but rather in the service layer "above" the provider.

It turns out that BlogEngine.NET caches all of your blog posts in memory -- regardless of whether you choose to store them in XML files or in a SQL Server database. And it's not just the post summary information that is cached in memory. Rather it's the entire content of each and every post.

Specifically, in BlogEngine.NET all of the post content is stored in a static list -- which makes it even worse than if this same approach were implemented using the ASP.NET caching infrastructure. If the ASP.NET cache were used, then at least the underlying platform could do its job of effectively managing the memory usage of the application (assuming the full content of each post was cached individually).

When I discovered this, I did some quick searching on the BlogEngine.NET forums and found several other people complaining about the same issue. I also found references to BlogEngine.NET deployments with many more blog posts than I currently have, which made me wonder how they were able to cope with what I consider to be a fundamental flaw in the architecture of BlogEngine.NET.

The reason, it turns out, depends entirely on what your deployment architecture looks like. In other words, are you running BlogEngine.NET on a dedicated server with multiple gigabytes of RAM? If that's the case, then the approach taken by the BlogEngine.NET development team isn't really an "architectural flaw" at all -- rather they are simply taking advantage of the "memory is cheap these days" mantra and it will take a lot of blog posts to consume even 1GB of memory.

However what if, like me, you are running in a shared hosting environment? In that case, the "memory is cheap" excuse no longer holds true, because the hosting provider (e.g. WinHost) needs to run many different websites on a single server. If your application has a large memory footprint, then it is not a good candidate for shared hosting. [Note that I never saw anything from WinHost regarding how much memory consumption would be considered a problem. Rather my gut told me that if I continued with BlogEngine.NET then eventually I would hear from the WinHost support folks telling me I either need to consume less memory or move to a dedicated hosting plan instead.]

Thus began my search for another blogging solution.

After some more looking around, I discovered a few other potential candidates:


Note that I didn't spend any significant time looking at Oxite, since CodePlex clearly states it is no longer being worked on. However, it did lead me to the Orchard CMS project which looked very first.

Orchard CMS

It's worth emphasizing that Orchard is a Content Management System -- not just a blog engine. In other words, while it includes blogging functionality "out-of-the-box", it also provides the core infrastructure for many other types of website content.

When I discovered that Orchard is powering the blog for the renowned John Papas, I thought surely this would be the just the cure for my BlogEngine.NET woes. Consequently, I downloaded Orchard, installed it on one of my development VMs, and proceeded to setup a test blog with some sample content from my old MSDN blog.

After my experience with BlogEngine.NET, you can imagine that I was feeling a little "gun shy" about free, open source applications for blogging. As such I quickly started looking at the underlying architecture of Orchard, rather than how it appeared on the surface from the administrator and blog author perspectives.

Like BlogEngine.NET, Orchard appears very "polished" and was a breeze to setup. Orchard is also very extensible.

Unfortunately, I quickly discovered a couple of issues with Orchard that left me feeling a little queasy.

The first is what appears to be a rather obvious bug that is described in a question posted on Stack Overflow:

The second issue is related to the fundamental architecture of Orchard. When I used SQL Server Profiler to inspect the database calls for one of my sample blog pages (as described in one of my previous posts), I observed over 40 separate round-trips to the database just to render a single page. [Note that I am going off memory here from a couple of months ago, so I could be wrong about the number -- but I seem to recall something in the neighborhood of 42-44 round-trips to SQL Server.]

In my opinion, the Orchard team has made a substantial tradeoff in optimization (i.e. minimizing the number of database calls required to render a page) in order to achieve a highly componentized architecture and what they call "UI composition" (e.g. content item → content type → content part). While I admire the ultimate goals and flexibility in the Orchard architecture, it seems a little too "ivory tower" to me and I wonder how Orchard scales in real world deployments.

By comparison, SharePoint typically requires only one or two database round-trips to render a page (once the site is warmed up, of course). Note that in SharePoint-Land, a single round-trip to SQL Server often includes multiple stored procedure calls or T-SQL statements batched together. The key point to understand is that SharePoint tries to fetch everything it needs from the database to render a single page using a very small number of round-trips to SQL Server, because the SharePoint team -- like me -- believes the key to scaling massively is to minimize your "off-the-box" calls.

Based on what I saw in my cursory examination of the Orchard architecture, it seems like Orchard would require substantial rework in order to batch multiple calls to the database into significantly fewer round-trips to SQL Server.

Consequently, I moved on to looking at another CMS solution that includes blogging functionality, namely Umbraco.


Umbraco is relatively easy to install and configure, but I discovered some issues when you want to run it in isolation within your site. For example, as I mentioned in my previous post, I was looking for a blogging solution to serve content from the /blog folder of while other areas of the site are served from a different ASP.NET application.

In this configuration, I encountered an error similar to the one described in the following issue:

Fortunately, a little digging around led to the corresponding fix:

xslt assumes Blog is in root

However, the more I looked at Umbraco, the more I felt like it was too complex for what I was looking for. The more I dug into Umbraco, the more I thought about how much time I would need to invest in learning yet another CMS solution. Since SharePoint is one of my core competencies, I honestly don't see myself recommending Umbraco over SharePoint for the size of companies that I tend to work with.

Right about the time I started looking into customizing the "master page" in Umbraco, I decided to once again pull the plug.

At this point, I was getting quite frustrated in my search for a replacement to my original choice of BlogEngine.NET. In fact, I even thought about writing my own blogging solution (albeit with minimal functionality).

Fortunately, that's when I discovered Subtext.


If you've ever caught yourself throwing your hands in the air and declaring that you're going to write your own blogging engine, then Subtext is for you.

When I read these words, I got goose bumps. Okay...not really...but they certainly did resonate with me based on my recent experience.

Fortunately, Subtext was a breeze to install and I don't recall hitting any snags right away (unlike my experience with Orchard and Umbraco). More importantly, however, after looking at the underlying architecture of Subtext, and "sniffing" the database traffic using SQL Server Profiler, I had a much better feeling about it than I did with any of the other blogging solutions I considered using.

Subtext does a fair amount of caching, but it does so in a way that I consider to be much "smarter" than BlogEngine.NET -- and the fact that it actually does caching seems to make it a more logical choice than Orchard -- at least at this point in time. [That's not meant to bash the Orchard development team. I sincerely hope that in the near future, they turn their attention to optimizing performance and scalability.]

Subtext is definitely not as "polished" as BlogEngine.NET or Orchard from a UI perspective (and to be honest, you can tell that Phil doesn't place a great deal of value on the look-and-feel of the blog admin pages). Nevertheless, the core functionality appears to be very solid.

Are there bugs in Subtext? Sure...there are bugs in every piece of software out there.

Did I encounter any issues with Subtext while implementing it on Well, yes, as a matter of fact I did.

Fortunately, though, it didn't take very long to get up-to-speed on the inner workings of Subtext, and I was able to make the necessary tweaks that I needed along the way.

I'll explain more about those "tweaks" in subsequent posts.


  1. # re: Building, Part 1 (a.k.a. Why was Subtext selected for

    November 22, 2011 11:19 AM
    [SPAM] I like all you posts, they are all very informative and useful. This one is not the exception! Thank you very much for you work and keep up!
  2. # Ms

    December 4, 2011 12:07 PM
    [SPAM] I am truly satisfied by reading this post. You gave me a big inspiration. Thanks for letting me know about this stuff!!!
  3. # re: Building, Part 1 (a.k.a. Why was Subtext selected for

    December 4, 2011 12:47 PM
    [SPAM] This is a great article, and a great topic to explore. Thanks for sharing.
  4. # re: Building, Part 1 (a.k.a. Why was Subtext selected for

    December 10, 2011 7:28 PM
    Simon Philp
    Hi Jeremy, welcome aboard. If you've not done so already make sure you get askimet up and running and check the links people are posting when commenting for example the 3 above this one....

    Also be sure to check my site, has some subtext skins and nice hacks ;)

    Catch you soon. Any questions please feel free to email me.

  5. # re: Building, Part 1 (a.k.a. Why was Subtext selected for

    December 19, 2011 5:58 PM
    Jeremy Jameson
    @Simon, thanks for the tip about the spam comments.

    Apparently I'm not getting emails from Subtext whenever someone leaves a comment -- so I need to look into that issue too (probably due to the originator email address being used by Subtext).
  6. # re: Why was Subtext selected for (a.k.a. Building, part 1)

    March 29, 2012 11:40 AM
    Never had real performance problems with Blogengine.Net. Maybe the only when you deploy the new solution, but once the data is in memory, it goes fast. I run it on a cheap provider, still no real problems there.
  7. # re: Why was Subtext selected for (a.k.a. Building, part 1)

    March 11, 2014 10:23 AM
    I run it on a cheap provider, still no real problems there.
  8. # TU

    April 4, 2015 10:06 PM
    Hey would you mind stating which blog platform you're using?

    I'm planning to start my own blog in the near future but I'm having a hard time
    selecting between BlogEngine/Wordpress/B2evolution and Drupal.

    The reason I ask is because your design and style seems different
    then most blogs and I'm looking for something completely unique.
    P.S My apologies for getting off-topic but I had to ask!
  9. # re: Why was Subtext selected for (a.k.a. Building, part 1)

    April 5, 2015 12:43 AM
    Jeremy Jameson
    @Kaleski: This blog is still running on Subtext after all these years (although I haven't written a blog post in a long time).
  10. # re: Why was Subtext selected for (a.k.a. Building, part 1)

    August 10, 2017 4:26 PM
  11. # re: Why was Subtext selected for (a.k.a. Building, part 1)

    December 5, 2019 7:26 AM
    file retrieval
    Magnificent goods from you, man. I've understand your stuff previous to and you are just extremely excellent.
    I actually like what you have acquired here, certainly
    like what you are stating and the way in which you say
    it. You make it enjoyable and you still take care of to keep it wise.
    I can't wait to read much more from you. This is really
    a terrific website.

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Apple

Please add 1 and 2 and type the answer here: