Monday, September 20, 2010

Optimize Sitecore Performance Checklist


Greetings! I’ve stumbled upon this hot discussion on StackOverflow about Sitecore CMS performance and could help but sharing a few thoughts on the subject.
The message I am trying to convey is that the product is built for performance and scalability. After seeing a fair number of successful implementations that have the unlimited scaling capacity, it is sad for me to see some developers struggle.
We all love checklists, so here is a slightly modified list of things to look out for and try out when you start having performance degradation. Each case is special, so apologies if most of this is not applicable to your situation.


  1. Get to know Sitecore caching really well. As content volume grows, data caches need to be adjusted.
    http://sdn.sitecore.net/Reference/Sitecore%206/Cache%20Configuration%20Reference.aspx
  2. Messing with prefetch caches (the ones that is pre-populated on the start up) helps significantly.
  3. Take a look how much time it takes for Sitecore log file to be generated. It should be almost the same second as first request is hitting Sitecore. If it takes more than that to generate the log file, look out for this:
    http://sitecoreblog.alexshyba.com/2010/03/sitecore-startup-time-something-that.html
  4. Test your database connection.
    http://sdn.sitecore.net/Articles/Administration/Sitecore%20Performance/Storage/Database%20Administration/Testing%20Database%20Performance.aspx
  5. Don't recompile every time. This restarts app pool, which could be quite expensive. I do all sublayouts with CodeFile, not CodeBehind
  6. Visual Studio 2010 sometimes drops App_Offline.htm file into the web root any time I change a layout (at least for me). This restarts app pool. I am hosting all my layouts outside the web root in development and have IIS virtual directory setup to bring them into Sitecore. The idea is to minimize any changes within the web root as IIS is quite "panicky" about "critical changes in the web root".
  7. Move the /indexes folder outside the web root. This has been causing the IIS 7.x sites running under Integrated app pool to restart frequently during the index update.
  8. Monitor your Sitecore log files for any restarts. If new log file is generated, this commonly means a restart happened.
  9. Use the profiler like ANTS to look for other bottlenecks in your environment.
  10. Sometimes it is a access to a Windows temp folder that is not being granted and the main thread is waiting for this. Process Monitor is going to help you with that.
  11. Disable search indexing in development if you don't use it. You may be having a large search index which is getting rebuilt frequently, causing some painful IO. No bueno.
    http://sitecoreblog.alexshyba.com/2009/03/how-to-completely-disable-lucene-index.html
  12. Look out for other scheduled operations (publishing, link database rebuild, etc.) that may be running in the background and crippling your Sitecore instance.
  13. Get rid of that Centrino processor finally! And get some RAM. You can get an 8 core 8 Gb laptop for 2K now. Having a quad as your dev machine is pretty much standard these days. If you see SQL and W3WP process fighting for the resources, that would be the first thing I'd do.
  14. Other factors including network if you are working remotely, connectors/integrations that could be going outside for something. Disable them in dev if you don't absolutely need them.
  15. Sitecore Log files will show you how long each step took. This is very useful for advanced troubleshooting.image
  16. If everything above is complete nonsense to you, please connect with our tech support folks and we can take this problem further.
Of course, this is not a comprehensive list. It if just a start. Please share your experience, good or bad. If you have more ideas, please keep them coming!

2 comments:

Daniel said...

great resource, thanks!

welmblad said...

Very helpful - Thank you. I like to use a spreadsheet to keep track of the various caching parameters across our websites.