Mar 17 2008
3 Pitfalls to Avoid for a Faster Ektron CMS400 Website
Server performance is one of the most important functions of websites today. Users expect immediate response when clicking around your site. Even a 3.5 seconds delay may send them somewhere else. Also, search engine crawlers (like Google) will rank you lower as a result of high latency. Hence, it is not only important to practice a faster website delivery, it’s a necessity. Recently, we have assisted our clients with server performance, which we supported using Ektron CMS400 v7.0.4. Here are the three main server performances we have noted after testing and tracking down the cause of website delays by using the Trace technique in .NET:
1. Avoid XML/XSLT Tranformations for Controls Output
After researching the cause of a huge latency greater than 2 seconds on every page refresh, we have discovered that about 50% of the latency was during the Page_Load occurrence. A more thorough research revealed that the 50% in delay was occurring during the XSLT transformations of all the controls on the page.
By caching these controls, (this solution is only partial and not recommended), and changing the way controls are rendered onto the page, we were able to reduce this latency to less than half. Therefore, we recommend building your Ektron site with the basic Ektron controls, and if you need a special way to present the information, use the code behind to generate a display of the data while you gather the data through the Ektron API and process the data programmatically. In other words, avoid XSLT altogether.
2. Make Use of the Flex Menu Ektron Control
Most of the Ektron sites that we’ve had the chance to work on were structured similarly. The main menu was a set of multi-level menus, which are all rendered by a style-specific XSLT. In some cases, before running through the XSLT, a script was passing through the menu items to find the one that needed to be ’selected’.
Why should we reinvent the wheel?
If you read Ektron’s documentation, you will find a few menu controls that can be very handy: DHTMLMenu, Menu, SmartMenu, and FlexMenu. Each one has its advantages and disadvantages. In short about each one:
- DHTMLMenu: My least favorite. Uses too much JavaScript and doesn’t render nicely for SEO
- Menu: The simplest one to use for basic menu systems
- SmartMenu: I like this menu because it’s a styled and nested unordered list. It can also support section 508 and highlights the selected menu item by a client side script, which is a lot more performance friendly
- FlexMenu: Our tests indicate that this menu control is the fastest if you have a sophisticated XSLT. It seems like Ektron simply provided a flexible menu control specifically for XML transformations.
We recommend the use of the SmartMenu, and if you insist in using XSLT to display a menu, use the FlexMenu as the alternative.
3. Make Use of the .NET Caching Mechanism
A simple thing for developers to set, isn’t it? Well, you can’t imagine how many sites we’ve seen without any caching beyond what the default settings allow. There is so much more to cache, it is almost a crime not to make use of it in our technology-driven age.
Ultimately, the above lists are just a few main performance issues that we have found with many Ektron sites. The items above alone can improve the site’s performances by up to 50%. However, this list is far from complete by any means. Hardware, Paging, Deadlocks, Server Environment, and even Bandwidth need to all be reviewed in order to improve performances.
Fast Surfing!
Great article. Could you give some ideas on what you have done for caching pages with logged in and anonymous users? What did you vary on for Output caching.
Brian:
For reasonably complex sites, it’s usually better to cache at the user control level, not the page level.
For example, a static page footer that’s identical for all users, logged-in or not, can be aggressively cached. The footer could be written into an ascx user control that is shared across all instances.
On the other hand, a control that displays the current user name and login/logout link needs to be cached on a user-by-user basis:
For this situation, I’ve had good results using OutputCache and the VaryByCustom directive. In conjunction with VaryByCustom, override the GetVaryByCustomString() method in your Global.asax file and include logic to detect the current Ektron UserID. From there, a cache string can be constructed that is unique to each user.