Is SiteCore slow and buggy?

Question

I've seen plenty of negative comments regarding performance and general bugginess. However, to be fair, most of these look like they were within the v5.3 timeframe. Have they fixed all of those issues in v6.0? Is it an excellent product?

Some examples of the complaints:

Maybe it’s just a case of user error, but this guy says, “some pages take as much as 20s to render…” Source

Here, in the comments, one fellow remaks, “Sitecore backend is incredible slow. Sitecore developement is really pain, it takes from 2 minutes to start sitecore and many many seconds to do small backend operations. They claim to have a quick client, but that is a BIG LIE. All developers in my company really hate sitecore for being so slow.” Source

Another search yielded, “Sitecore’s users listed three issues as number one: licensing, the server as a resource hog, and the site’s slow responsiveness.” Source

Answer 1

Out of the box, Sitecore speed or resource usage is not a problem, although it all depends on how it is configured and built upon.

We've been using Sitecore 5.3 for two years now with around 10k content pages. A project required the storage of 50,000 images and storing these within the sitecore media library db (sitecore can also store media on disk) meant that, after logging in, the first permissions task (edit, lock, save etc) took ~4 mins. Removing the 50k images fixed that - we're now down to 10k pages, 10k images and it's fine.

There are several installation/configuration/development decisions that can affect performance if not chosen wisely:

• Sitecore can use MS SQL (2005/8), SQL Express or SQLite - i think 2005 is recommended, which is what we're using.
• Configuration of IIS application pool - memory limits, worker pool recycling etc etc
• Sitecore can run in development/live mode, where there is a content editing server which publishes to a web server or live mode, where the same server is used for both
• The pages can be built in xsl or code-behind. XSL is fast to develop and render but is not as powerful, as IIS only uses XPATH 1.
• Sitecore caching, if properly used, is very very good.
• There are certain content decisions, such as storing content items in folder structures, which can affect performance if done wrongly.

Most of these are either plain common sense or obvious once you have a little background knowledge of Sitecore.

We're taking the opportunity to move to Sitecore 6 while we do a redesign, and it's even more optimised than 5.3

Answer 2

I used to develop for 5 years websites with Sitecore. It is true that Sitecore backend (Shell) is very slow. If you install empty Sitecore it is fast but once you actually start to have content in it speed goes down very fast. It helps a bit to run SQL 2005 compatibility mode (notice Sitecore 5.x installs db's in 2000 compatible) also in IIS is a good tip to use content caching. However, these tips wont make backend much faster. In fact I was never able to make 5.3.x shell fast but 5.2 last builds are the fastest in V5 serie. In version 6 Sitecore introduced Page Edit which is their implementation of "Edit-In-Place" concept which works more or less but you still need to load sometimes Sitecore backend GUI that slows down. Anyway Page Edit is definetly right direction and I am looking forward to see next major release of Sitecore where hopefully they have worked out some of the slowness on Page Edit. If you develop site in Sitecore 6 I suggest implementing all Editor tools in Page Edit so normal editors will never see anything else than Page Edit. It's also userfriendly.

But notice that Sitecore is only slow in the back-end when you login as Administrator (that loads all bells and whistles). If you setup Sitecore security correctly you will have Editor role that has limited access and will not see all ribbons when using Sitecore on Editor mode speed should be OK.

In frontend website is fast as any .NET application, you can cache static renderings that works very nicely. You have very good debugger mode that helps you find problems if you need heavy tuning but in general issues in frontend are usually developer errors that you need to know like in .net never refer XML in "//" due performance issues in xPath.

Even though all the rant about shell I still think it is the best CMS tool I have been working with. Especially if you need to make integration, complex graphical design or you have many editors. IMHO unlike product like Sharepoint developers actually love to write code on it. :)

Answer 3

I must agree that sitecore is very slow. After working 3 years with sitecore I can say that developing sitecore is just a waiting process. Whatever you do in sitecore, as soon as you have a couple of items in it, you have to wait.. A heavy solution can take up to 2 minutes or more to restart. So if you have some c# code you have to debug, the development becomes really counter productive and whatever estimation you give for a task, it will always take more with sitecore. Developers are loosing patience because every time you compile and debug, you have to wait.. Then when you test stuff in backend, again, you have to wait after every click. That's why I say "Sitecore is all about waiting..". It is so bad, that some pissed of developers use nicknames like "shitcore" when working. And what I notice in my company is that, because of slowness of the cms, developers will always try to use hacks and quick fixes, so that finishing a task won't take so long and inevitably that leads to poor quality. There's just not enough time to make quality code in a sitecore solution.

Answer 4

I have to agree that Sitecore is inherently NOT slow. I've worked with a number of mid-level CMS products on the Microsoft stack, and I am by far most impressed with Sitecore.

Granted, I've worked primarily with version 6.X, so I'm less familiar with the performance issues that may have existed prior to that.

But here's the thing: a high-performance Sitecore implementation requires two things:

1) A sensible information architecture 2) Taking advantage of their caching framework (it's quite sophisticated--goes well beyond ASP.Net's out-of-the-box framework)

There are other tweaks you can make to their system on your production environment to improve performance. And of course you need to make sure that you're using best practices for performance: GZIPing responses, setting long-term cache expiration on your permanent assets, minifying and combining your Javascript files, using sprites for your page design images, using Viewstate only when necessary, and doing everything possible to reduce the number of requests to the server and the size of the responses.

If you're willing to invest some effort in improving performance, you can get fantastic results with Sitecore. And the fact is MOST of the improvements you'll need to do have nothing to do with Sitecore itself. Instead, they're just basic best-practices which will apply to any CMS or platform you're on.

Answer 5

I'm also experiencing performance issues with Sitecore. I'm not entirely sure if it's the network bandwith or the computer I'm using that is to blame for the crap performance.

What is your recommended hardware setup for a Sitecore developer? By recommended I mean, a proper setup which gives the best overall performance for developing (aka recompiling when debugging). I don't have a problem with time if I'm just creating renderings, since xslts doesn't require half the time to get the sitecore solution back up and running after an alteration.

Edit: Noticed I've added this reply as an answer, which it is not. However, the reply concerns the overall performance of Sitecore while developing.

Answer 6

I think you guys are developing incorrectly. You shouldn't be re-compiling Sitecore when you are developing, only the bits you are adding. You should have the sitecore folder and sitecore modules folders excluded. You should be creating a new namespace that the layouts are in and hence create a dll with that namespace. this way you can separate all the different sites in your solution. I used to have all these slowness issues but now I always develop from a new fresh instance of Sitecore. Then when its don, I just copy up the dll and the layouts (and any js, css, images, xslt files).

As for slow performance, I have learnt that you can't treat Sitecore sites the same as normal CMS sites. You need to carefully organise your items. I have seen a solution where the first thing that happens is every item is loaded up at once. This is really REALLY not helpful.

Answer 7

Guys,

I've been working with the system from Sitecore 4 days and seen hundreds (maybe even thousands at this point) of Sitecore installations out there in the wild. There are just too many factors adding up when you are having performance issues of your dev environment.

Sorry, but claims like "Sitecore is slow" are not really helping in understanding the problem.

As Adam mentioned, out of the box Sitecore is flying. The rest depends on your environment, hardware, configuration (cache is a big thing), SQL, custom code, architecture of the content tree, how you do builds, etc. etc.

To give you an example, I am running 20 fairly sized Sitecore instances on my laptop. Sometimes 2-3 at the same time. That includes demo sites and customer installations with 4-7Gb master databases. Never have performance issues.

Full app restart after IISRESET takes 5-7 seconds on a fairly sized Sitecore implementation. Skype me and I will show you :-)

Things to look out for and try out: 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

1. Messing with prefetch caches (the ones that is pre-populated on the start up) helps significantly.

2. 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

3. Test your database connection. http://sdn.sitecore.net/Articles/Administration/Sitecore%20Performance/Storage/Database%20Administration/Testing%20Database%20Performance.aspx

4. Don't recompile every time. This restarts app pool, which could be quite expensive. I do all sublayouts with CodeFile, not CodeBehind

5. Visual Studio 2010 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".

6. 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.

7. Monitor your Sitecore log files for any restarts. If new log file is generated, this commonly means a restart happened.

8. Use the profiler like ANTS to look for other bottlenecks in your environment.

9. 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.

10. 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

11. Look out for other scheduled operations (publishing, link database rebuild, etc.) that may be running in the background and crippling your Sitecore instance.

12. 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.

13. 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.

14. If everything above is complete nonsense to you, please connect with our tech support folks and we can take this problem further. Time spent well comparing to coming up with nicknames ;-)

Answer 8

I held a webinar recently on improving performance in Sitecore websites: http://blog.capaxsolutions.co.uk/2010/08/11/video-of-sitecore-performance-webinar/

The long and short of it is that Sitecore is built with very large websites in mind, if it's running slow then there has to be something wrong. The good news is that it's always something solvable, typically it's something simple like an errant control or an under spec server. If it isn't simple then there is also a wealth of reporting tools that can help you track down the problem.