Architecture, Sitecore

Dedicated image server and Sitecore

A lot of sites which have a large amount of visitors use a dedicated image server.  There are several reasons for this, but mostly it is because that most browsers only allow a few simultaneous connections to the same domain, which stalls the download of a page that has more than two resources. For instance imagine you have a page consisting of multiple images, stylesheets and javascript files. As the clients only allows a few simultaneous downloads, the browser won’t download all the resources at the same time, but wait for each download to complete and first then start the next download.

The reason of this behavior is that the HTTP standard says that only two simultaneous connections between a client and a server should be allowed. This was specified to save servers from heavy IO load, when files where requested. Browsers like IE7 and Firefox 2 lives up to this standard and only allow 2 connections, while new browsers like IE8 and Firefox 3 allows 6 connections.
To ensure that the HTML can be fully loaded independently and without waiting for other downloads and to remove the load from the primary web server; a dedicated image server can be used. This server holds all files and uses a different domain (for instance images.mydomain.com). All files used on the page can then be fully referenced and thereby be downloaded from a different domain. Eg <img src=”http://images.mydomain.com/image1.jpg alt=”image1”/>. As the images are now on a different domain, these can be requested independently of the server providing the HTML and more simultaneous connections can be opened.

But how is this possible in Sitecore where the media library controls all the images?

One of the easiest ways is to have another publishing target for the media. In that way you will have two frontend servers: One serving the normal requests and one serving all media items. You can easily set up another publishing target and for instance use the staging module to clear the cache. Read more on SDN if you want to know how to set it up.

The remaining problem is: How do we ensure that all media items gets prefixed with another domain? Unfortunately there isn’t a simple setting for this (it will probably come in a future a release of Sitecore – I hope :)). However there is a simple solution to the problem as links are expanded by the LinkProvider, which can be overridden. More precisely the links are expanded in the LinkProvider.ExpandDynamicLink method, so we need to override this replacing the media path:

namespace TestApplication
{
  public class CustomLinkProvider : LinkProvider
  {
    public const string MEDIA_PATH = “~/media/”;

    public override string ExpandDynamicLinks(string text, bool resolveSites)
    {
      string baseExpands = base.ExpandDynamicLinks(text, resolveSites);
      return baseExpands.Replace(MEDIA_PATH, “http://images.pentia.dk/” + MEDIA_PATH);
    }
  }
}

Here I override the ExpandDynamicLinks in the inherited class CustomLinkProvider. I replace all media paths (identified by the prefix ~/media/) and replace it with the full path to the image server. The remaining thing to do is to replace the LinkProvider type in the web.config:

<linkManager defaultProvider=”sitecore”>
  <providers>
    <clear />
    <add name=”sitecore” type=”TestApplication.CustomLinkProvider, TestApplication” addAspxExtension=”true” alwaysIncludeServerUrl=”false” encodeNames=”true” languageEmbedding=”asNeeded” languageLocation=”filePath” shortenUrls=”true” useDisplayName=”false” />
  </providers>
</linkManager>

Here I just point the LinkProvider type to my own implementation.

Now that this is set up, all requests for media items will be handled by the image server. This does not just allow faster load times for the client, but will put less pressure on the main server. Further you can tune the media server to handling media items by increasing the media cache, setting the prefetch cache etc.

Enjoy your new Sitecore media server 🙂

Standard
Architecture, Sitecore

Agile Sitecore design

It been a while since my last blog post – my second child Annika was born March 16th and since then I’ve been forced to realize that two children takes up a lot of blog-writing time.

A year ago I wrote a post titled Type before function, which pointed out the very type-centric design of Sitecore. Since then, we have in Pentia tried to develop a design practice which focuses more on isolating logically grouped functionality in our design and thinking outside the type-centric nature of Sitecore. For this purpose, we have “invented” the term component in our design. The purpose of components is to separate the functionality from the type, allowing the developer to focus on one purpose and its interfaces.

The practise has been quite successful – our large-scale solutions have become increasingly easy to maintain and extend. As a side effect of the process, we now have a high degree of reuse – not just knowledge, but actual code – between even seemingly un-similar projects. Not very surprisingly, it turns out that developers are more inclined to reuse code, which is easily overviewed. The design practice is so successful, that we have passed it on to external projects, through our Professional Services.

Here are a few tips on getting you started:

Consistent placement and naming

Not all items belonging to a component can be placed together. Naming and placement makes it easier to identify component items – in a type-centric system.

Keep your files together – we never use the standard Sitecore folders, e.g. /xsl and /layouts. All files in a component are placed below a folder named /Components/[ComponentName]. This makes it easy to identify which files belong together without e.g. garbling the filename with unnecessary prefixes. And if you think about it, it’s not hard to identify a file as an XSLT – so why put it in the/xsl folder? Keeping component items together also goes for templates, renderings and layouts in Sitecore. For the purpose of Sitecore best practice, we still place templates under /sitecore/templates (although I suppose it’s not strictly necessary), and layout items under /sitecore/layouts. But we always use subfolders which are named consistently, e.g. /sitecore/templates/Components/[ComponentName].

Component projects

Each component has a separate Visual Studio project, and therefore a separate assembly. Aside from grouping files even further, this also helps to identify dependencies between components. Use build events on the project to move files from component folders to website folders if needed.

Interface templates

Think of templates in Sitecore as interfaces – never basetypes – which provide your pagetypes or data items with certain functionality. Always refer to these interfaces in the code within the components.

Example: The component Navigation (menu, breadcrumb and sitemap) defines the template Navigable with the fields Menu Title and Show In Menu. This template is assigned to the pagetypes which can be shown in the menu. The renderings Menu.xslt and Breadcrumb.xslt only references the Navigable template by using the XslHelper.IsItemOfType() method (or your own more optimized version).

Common components

There are a number of components which is always in a project, and which brings the functionality of the other components together.

The Design component contains all the graphic design for the project. Do not be tempted to place stylesheets and graphics within each component – the design for a single component is always related to other components, and therefore you will be forced to create unnecessary dependencies.

The PageTypes component brings together the interface templates and renderings and sublayouts in the other components on the actual page type template. Only page type templates are instantiated in the content tree. If you define the page type template News in the News component and not in the PageTypes component, you will be forced to create dependencies to other components e.g. Navigation.

Dependencies and Inversion of control

Keep your dependencies amongst components as few and as obvious as possible. It should not be necessary for a developer to know more than the component he is working on – too many dependencies makes the components too complex and less flexible. The common components is one way to reduce dependencies, another is the use of the inversion of control pattern and possibly an IoC container. Suppose the News component uses the Indexing component for providing data quickly. This could naturally be done by calling the indexing component directly through the News code, thereby creating a dependency. Alternately the News component could provide an appropriate interface which defines its necessary functionality. This interface could be implemented by the Indexing component and instantiated though Reflection or an IoC container like Unity or Spring, thereby inverting the dependency and making the News component more lean.

Standard
Uncategorized

Type before function?

I’ve recently been made aware of how type-centric Sitecore is in its architecture and best practices.

Consider the main sections in Sitecore: Content, Templates, Layouts, and even the folder structure /xsl, /layouts. Sitecore seems inherently to point the architect towards categorizing his solution after which types of elements it consists of, i.e. which templates do my website consist of, how many layouts do I have, which XSL’s do I have to write etc. instead of looking at the conceptual structure of the website, i.e. which functionality do I have, e.g. newsletter, document, navigation etc. Trying to piece together all the parts which make one function on the website involves browsing through a lot of folders in Sitecore and looking into a lot of code, whereof many of the references are very loose e.g. template names in XSLT files, or assembly references in the web.config (or even worse: assembly references in Sitecore). All in all it is not an architecture which is very helpful for reuse and overview.

I vision Sitecore in a future version working in a more functionality-centric way, for example imagine the Sitecore content tree:

  • /sitecore
    • Content (This is where the editors edit the site – not much different here)
    • Components (This is where we – the developers – roam)
      • Component (each functionality has its own section)
        • Templates (this defines the templates for this component)
        • Presentation (This defines all the presentation elements for this component, layouts, renderings etc.)
        • Settings (General settings, dictionary texts etc. needed by the component)

…and that’s it. No more browsing the entire tree looking for the settings for the Mailing list module. No more: “I wonder if this layout is used by any of my 367 templates”. No more: “Was that document.xsl or document.ascx”. Just imagine the ease in making of package for porting functionality to a new website.

Just my two cents…

Standard