Svante Seleborg
Apr 14, 2011
(4 votes)

1Gb ought to be enough for anybody!

If your EPiServer site consumes more than 1Gb, and you can’t explain in measured detail why, you probably have a problem.

I’m often called in when EPiServer sites have problems under load in live production settings. Problems that can’t be reproduced in the development or staging environments. Problems that are not resolved despite upgrading the server memory, running web farms, installing more CPUs or implementing more caching.

Some of the problems concern unchecked memory consumption with forced recycles as a result. Others concerns hangs and crashes, but this post is about high memory situations.

A small-to-medium site should run perfectly fine in 300 – 500Mb, a very large one should do well in 1Gb. I’ve yet to see a site that really requires significantly more than 1Gb.

This has become even a larger issue with the advent of 64-bit Windows and .NET – now servers often have 16Gb or more memory, and few consider why a single EPiServer site with perhaps 100,000 pages would need that much memory.

Do the math! Let’s say the site uses 10Gb of memory, and let’s say your site has 100,000 pages whereof 10,000 is the ‘working set’, i.e. frequently requested directly or indirectly. That means the site is using 1Mb / page! Even with both internal and output caching that’s simply not reasonable except in a few very special cases.

There are many possible reasons for excessive memory usage, but they are not true memory leaks. It’s just a question of your code holding references to more instances of objects than you may be aware of. Some reasons include attaching instance event handlers to static events, excessive string duplication (do consider using String.Intern() for commonly used strings such as URLs and parts thereof), page instance methods adding data to static collections and unawareness of implications of keeping references around to system objects (they are larger than you may realize). Generally speaking, almost all memory problems come from adding object references to static collections either in per URL code or even worse, per request code.

If you do have a site with more than 500 – 700Mb of memory usage, and you don’t really know why, check it! When I say that you should know why, I mean that you should have measured the memory and know what it’s used for – not just assume for example that a caching scheme is responsible.

Measure it! But how? Take a memory dump and use WinDbg from Debugging Tools for Windows. The standard place to start is . Load the dump and SOS.dll and then do:

!dumpheap –stat

!dumpheap –strings

You’re sure to find food for thought…

Apr 14, 2011


Please login to comment.
Latest blogs
Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023

How to Merge Anonymous Carts When a Customer Logs In with Optimizely Commerce 14

In e-commerce, it is common for users to browse a site anonymously, adding items to their cart without creating an account. Later, when the user...

Francisco Quintanilla | Mar 27, 2023

How to Write an xUnit Test to Verify Unique Content Type Guids in Content Management

When developing an Optimizely CMS solution, it is important to ensure that each content type has a unique GUID. If two or more content types share...

Minesh Shah (Netcel) | Mar 27, 2023

Extend TinyMCE in Optimizely CMS 12

Since technologies are upgraded to newer versions the ways to extend or override the out-of-the-box functionality are also changed a little bit so...

Ravindra S. Rathore | Mar 27, 2023 | Syndicated blog