The challenges of a high traffic site with EPiServer

…with an unconventional approach to data fetching.

This article is a first of a series describing the faceted navigation system for EPiServer that we have internally developed in Cognifide and that’s already proven to be a robust solution for delivering tagged content a heavy traffic site, which will be released shortly as an open source project. The article outlines some pitfalls of EPiServer that we’ve run into and the nature of the project in which the module was used first and which influenced a lot of our design decisions.

This article and the Faceted Navigtation module is developed on EPiServer 4.61 and not the latest version 5 of the CMS so far, so mind that some of my reservations may not be a problem if you’re just starting to work on a brand new project and have the luxury of using new features of it.

Also (which may be a good thing) our sites uses a different approach to navigation the content, we do not really care much for the tree structure, but we treat all EPiServer pages equally when looking for content because of how the site is designed from the creative point of view.

Read the rest of this article »

This is a slightly dated post (written around November last year), that I forgot to post some time ago, so bare in mind, we’ve already started working on the faceted navigation getting open source status and I’ve updated the first sentece to include Adam Matusiak joining our team – Welcome Adam!

LocutusBorgQueen Over the last month or two  our hive mind has assimilated two new voices, our thoughts have become one with Greg’s, and Adam’s.

But seriously, the EPiServer (and consequently the .Net) part is getting really strong with eight nine(!) developers on that side currently working on a number of projects and that’s just developers!

What I really like is that we’re not just consuming the APIs, we already have developed some very cool technologies and the best part is that we’re starting to look seriously at open-sourcing some of our technologies to make the EPiServer community benefit from our experience. As a part of Cognifide Labs (that we hope to evolve in shape of Google’s “Pet projects”, I’m really looking forward to that). I’ll be working in my spare time on making our page commenting engine as well as our faceted navigation engine public consumption ready and ultimately add to the EPiCode experience. These are some modules that we’ve been working on for a long time, but just so busy with the various project development we’ve never been able to make them commented and documented enough for it to be a viable for a 3rd party developers to grasp. But already the technologies proven to be robust, scalable and extensible to support sites with over 6 million page views per month and growing and the site being fast and responsive just like you were the only person visiting it, thanks to using our data caching/fetching routines. All of that despite of a number of content pages counted in tens of thousands now.

It’s good to be a part of the hive mind, especially as brilliant as this one, so give in …resistance is futile, you will be assimilated!

Would you be interested in working with us on the technologies? How much need do you have for an elaborate faceted navigation in your projects? Did you have a need to add a commenting (site wide) to a site that already works, in a way that is not intrusive and that allows you to moderate comments in with the EPiServer editing mode integration? Which one would you find more interesting for us to start working on making public?

Is EpiServer a hard-shelled clam or what?

As much as I seem to be enjoying my trip with EpiServer there are some little things I don’t seem to appreciate all that much and I’m not quite sure how to work around some of them in an elegant way.

EpiServer has a fairly advanced way of dealing with properties but it also seems to be a bit tough on the developer whenever you try to do something more than just strictly using its API-s. One of the areas I don’t really enjoy is the dealing with the pages that are expired or generally unavailable for the user for various reasons.

In the project that we’ve been implementing recently we needed to store page ids for further reference in numerous places and although this generally works, accessing a page that’s been deleted, expired or not published yet, has proven to be a challenge and I can’t seem to be able to find an elegant solution around it.

For instance, we have a list of bloggers, that are stored in our faceted navigation with links to their pages, our system lists them and the links to their pages, should someone’s page be unpublished yet – we run into problems.

Another good sample of where this is needed is a list of pages (A multi-page property of sorts). There seems to be no implementation of a multi-page property in EpiServer and the only reasonable implementation that I’ve been able to find is available through EpiCode. The following is it deals with the pages going in or out of the system, which leads me to think that the only way of checking whether a page is available for me is to instantiate it with all the consequences of it:

// get the page with error handling for // access denied or deleted page try { PageData page = Global.EPDataFactory.GetPage(pageref); isExternalLink = (page.StaticLinkURL != multipageLinkItem.Url); if (page != null && isExternalLink == false) _selectedPages.Add(page); } catch (PageNotFoundException notFoundEx) { // We should not add the page if it // does not exist } catch (EPiServer.Core.AccessDeniedException accessDeniedEx) { // User is not allowed to see page, skip it } catch (Exception ex) { // The page could not be loaded, for some other // reason. System.Diagnostics.Debug.Write("Page could not be loaded: " + pageref.ToString(), "PropertyMultiPage"); }

What I do not like about this part (of an otherwise remarkable piece) of code is that exceptions are not supposed to be the driving force of the program flow. But in this case they seem to have been forced to do it. It’s like I had to open a file to check its size or whether it even exists.

I can see why the system will not let me visit the page if I’m not allowed to do it as a user, but the fact that the API frowns at me whenever I even try to instantiate it just to check its existence or my rights to it has proven to be quite problematic. After all a user is not supposed to see a login screen in the list of pages, but rather when he/she enters a page that he/she no no rights to. Better yet, give me a way to check whether I even can access it.

Is there one already? Has anyone heard? Did anyone see?

EPiCode hits IRC

I’ve discovered yesterday on Steve’s blog that him and our other friends on EpiCode have gathered on IRC (something I’ve been lobbying here at our company for quite a while). Come, drop by, let’s meet!

I’ll definitely try to hang out there as much as I can. great to meet you guys.

As Steve suggests – grab yourself a copy of XChat or aMirc, connect to and /join #epicode
Read the rest of this article »

Posted in EPiCode, EPiServer, Software Development, Web applications
1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)