6
votes

Recently our customers started to complain about poor performance on one of our servers. This contains multiple large CMS implementations and alot small websites using Sitefinity. Our Hosting team is now trying to find the bottlenecks in our environments, since there are some major issues with loadtimes. I've been given the task to specify one big list of things to look out for, devided into different the parts (IIS, ASP.NET, Web specific). I think it'd be good to find out how many instances of the Sitecore CMS we can run on one server according to the Sitecore documentation e.d. We want to be able to monitor and find out where our bottleneck is at this point. Some of our websites load terribly slow, other websites load very fast. Most of our Sitecore implementations that run on this server have poor back-end performance, and have terrible load times after a compilation. Our Sitecore solutions run on a Win 2008 64 server with Microsoft SQL Server 2008 for db's. I understand that it might be handy to specify more detailed information about our setup, but I'm hoping we'd be able to get some usefull basic information regarding how to monitor and find bottlenecks e.d.

What tools / hints / tips & tricks do you have?

5
Most of your users use about 15% of what Sitecore or Sitefinity offer this is why you shouldn't host those large web applications. This is why they compile slowly. You should check if there is relation between compilation time and requests made to same application.eugeneK
What do you mean by using about 15% of what Sitecore offers? There is no relation between compilation time and requests made to the same application. I think I know where you are heading for, but we use Keep alive services to stop the web application from going to sleep. The app doesn't get compiled on the regular base.Younes

5 Answers

5
votes
  • do NOT use too many different asp.net pools, called and as dedicate pool in plesk. Place more sites on the same pool.
  • More memory, or stop non used programs/services on the server
  • Check if you have memory limits on the application pool that make the pool continues auto-restarts.
  • On the database, set Recovery Mode to simple.
  • Shrink database files, and reindex database, from inside the program
  • after all that Defrag your disks

Check the memory with process explorer.
To check whats starts with your server use the autoruns but be careful not to stop any critical service and the computer never starts again. Do not stop services from autoruns, use the service manager to change the type to manual. Also many sql serve services they not need to run if you never used them.

Some other tips

  • Move the temporary files / and maybe asp.net build directory to a different disk
  • Delete all files from temporary dir ( cd %temp% )

Be sure that the free physical memory is not zero, using the process exporer. If its near zero, then your server needs memory, or needs to stop non using programs from running.

To place many sites under the same pool, you need to change the permissions of the sites under the new share pool. Its not difficult, just take some time and organize to know what site runs under what pool. Now let say that you have 10 sites, its better to use 2 diferent pools, and spread the sites on this pools base on the load of each site.

2
votes

There are no immediate answer to Sitecore performance tuning. But here are some vital tips:

1) CACHING

Caching is everything. The default Sitecore cache parameters are rarely correct for any application. If you have lots of memory, you should increase the cache sizes:

http://learnsitecore.cmsuniverse.net/en/Developers/Articles/2009/07/CachingOverview.aspx

http://sitecorebasics.wordpress.com/2011/03/05/sitecore-caching/

http://blog.wojciech.org/?p=9

Unfortunately this is something the developer should be aware of when deploying an installation, not something the system admin should care about...

2) DATABASE

The database is the last bottleneck to check. I rarely touch the database. However, the DB performance can be increased with the proper settings:

Database properties that improves performance:

http://www.theclientview.net/?p=162

This article on index fragmentation is very helpful:

http://www.theclientview.net/?p=40

1
votes

Can't speak for Sitefinity, but will come with some tips for Sitecore.

  • Use Sitecores caching whenever possible, esp. on XSLTs (as they tend to be simpler than layouts & sublayouts and therefore Sitecore caching doesn't break them, as Sitecore caching does to asp.net postbacks), this ofc will only help if rederings & sublayouts etc are accessed a lot. use /sitecore/admin/stats.aspx?site=website to check stuff that isn't cached
  • Use Sitecores profiler, open up an item in the profiler and see which sublayouts etc are taking time
  • Only use XSLTs for the simplest content, if it get anymore complicated than and I'd go for sublayouts (asp.net controls), this is a bit biased as I'm not fond of XSLT, but experience indicates that .ascx's are faster
  • Use IIS' content expiration on the static files (prob all of /sitecore and if you have some images, javascript & CSS files) this is for IIS 6: msdn link
  • Check database access times with Sitecore Databasetest.aspx (the one for Sitecore 6 is a lot better than the simple one that works on Sitecore 5 & 6) Sitecore SDN link

And that's what I can think of from the top of my head.

1
votes

Sitecore has a major flaw, its uses GUIDs for primary keys (amongst other poorly chosen data types), this fragments the table from the first insert and if you have a heavily utilised Sitecore database the fragmentation can be greater than 90% within an hour. These is not a well-designed database and recommend looking at other products until they fix this, it is causing us a major performance headache (time and money). We are at a stand still we cannot add anymore RAM cannot rebuild the indexes more often

0
votes

Also, set your IIS to recycle the app_pool ONLY once a day at a specific time. I usually set mine for 3am. This way the application never goes to sleep, recycle or etc. Best to reduce spin up times.

Additionally configure IIS to 'always running' instead of 'on starup'. This way, when the application restarts, it recompiles immediately and again, is ready to roar.

Sitefinity is really a fantastic piece of software (hopefully my tips above get the thumbs up, and not my endorsement of the product). haha