World is now on Opti ID! Learn more

Svante Seleborg
Apr 14, 2011
  3589
(0 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 http://blogs.msdn.com/b/tess/ . Load the dump and SOS.dll and then do:

!dumpheap –stat

!dumpheap –strings

You’re sure to find food for thought…

Apr 14, 2011

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |