Sitefinity 4.3 performances

Hi,

Despite the usual new version claims that Sitefinity is now faster or much faster than before, performances are bad here. Really bad. It might be faster in some cases (not sure, could just be a placebo effect), but in other cases, some operations now take several minutes (not a typo).

First, trying to remove the newly-added "Email Campaigns" link at the top took me ages. I did so going through Administration / Backend pages, then selected Email Campaigns / Title & Properties, and unchecked the "Show in navigation" box. As you save, you'll get a now classic Sitefinity bug: saving doesn't work because one of the properties has a default value which isn't valid. In this case, the URL contains a space. After fixing this by removing the space, the old URL gets added as an additional URL, although it isn't a valid URL. Uhh, okay. But anyway, bugs aside, as I saved the page, I had to wait a few minutes to be redirected to the index with all the backend pages, then a few more minutes for the loading GIF to disappear.

This is not an isolated problem. Going to the Pages section is often slow as hell (although I do not have many pages). Sometimes, it is also fast. After more testing, I think I found out how to reproduce this reliably: if all page groups are folded as I leave the page, then go back to Pages, then it's fast. If one group is unfolded, and I leave the page, then go back to Pages, then I have to wait several minutes. Can anyone confirm this?

My colleague, Nicolas, is in an even more frustrating situation, as he's working on a multilingual site, which brings loads of additional issues.

This is unacceptable. It's almost been a year since the first 4.0 release, and the whole thing is still nowhere near usable. Meanwhile, efforts are spent on an Ecommerce module. Seriously. I'd laugh if this didn't make my life miserable. This isn't a free opensource project, we're paying for this. I don't want to turn this into a rant, so I'll leave it at that.

I can reproduce the performance problem described above on the same site on 4.2 SP1. So it seems this isn't a regression.
However, my colleague cannot reproduce this issue on his own site. So there must be something specific about my site which triggers the problem.

I'll keep investigating.

Well, I have finally upgraded one of our projects that was on 4.1 to 4.3 and there were not major issues at all.

One small note for @Telerik though, when I went to hide the Email Campains Module in the Back-end from the navigation, I got the "The URL contains invalid..." when unticking the "Show in navigation" check-box. So I just adjusted the URL for the Module in question and it worked fine. Please check fro next release.

I then did some performance tests, only a couple, nothing major, and found the difference to be about 23% improvement from 4.1. That was me with a stop-watch trying to catch the events as best as I could. Whilst I was anticipating more, I am still happy that we are going in the right direcftion. In some cases, when accessing a page in edit mode that was not accessed in a long time (hence not cached), I was unable to record major improvements. having said that, I will leave it until tomorrow and then try to measure the performance improvements for un-cached pages since that is the most painful area. When trying to access a page that was not accessed in a long while, that is when it gets painful, but I am leaving that for tomorrow.

Otherwise, it seems stable so far. I am still testing it and will return to report some more in due time.

Many thanks,
Andrei

More info about our perf problem:

- The problem doesn't happen when running the application locally (from Visual Studio), only when the app is running on distant servers (so this could be related to the configuration / software on these servers)
- The perf problem seems to be time-out related, as it takes exactly 130 seconds each time before the Pages section is loaded (again, only when a page group has been unfolded before, otherwise it's fast)
- I tried to debug the problem with our server team, checking out logs / process monitor. It seems the application is stuck trying to communicate with the database. Then, in the end, there's a "NAME NOT FOUND" error on "webresource.axd" (located at the root of the site)

Can anyone help? Thanks.

Hi Thomas,

Can you please share a little bit more with us about on your website configuration?

What is the hosting provider? IIS version, OS version? Is the webapplication server in the same network with the database server

Do you have caching enabled, have you enabled output caching?

Is it possible that the website is running in debug mode?

Also see if setting a machine key in your webconfig as well as static content expiration as bellow alleviates the problem:

Hi Radoslav,

Thanks for your answer.

"What is the hosting provider? IIS version, OS version?"
Windows Server 2003, IIS 6.

"Is the webapplication server in the same network with the database server"
It's the same network, but different subnet.

"Do you have caching enabled, have you enabled output caching?"
What cache are you talking about? Where?

"Is it possible that the website is running in debug mode?"
It is deployed in Release mode.

"Also see if setting a machine key in your webconfig as well as static content expiration as bellow alleviates the problem:"
Just tried it, it made no difference. I also tried disabling event validation and viewstate, just in case.

Let me know if you have more questions.
Thanks.

Edit: I tried a backup of our app, and it's fast. So it must be something that changed in the app. Will keep you updated.

First time access is still very slow. Radoslav, my <system.webserver> does not have most of the stuff that your snipet shows. Should I add it manually?
Cheers.

I finally managed to track down the guilty line, in the web.config file:

Under <httpModules>:
<add name="JsonCompressionModule" type="MyPrivonline.Core.HttpModules.JsonCompressionModule"/>

Removing it fixes the perf issue. This references a home-made assembly of the company I work at.
I'm not sure whether we actually need this line for our site. If it's just for data compression, this could be optional.

Hello Thomas,

Thank you for updating us on the issue. By default Sitefinity uses 2 types of caching for its assets (pages, content, media content in library modules, and themes registered under ~/App_Data/). It uses output caching (based on .NET caching provider) for pages and content. This caches output html in server's memory to prevent data access operations while cache is valid. We also use browser caching by setting static content expiration headers for media items and items from your themes. This tells the client browser to cache the CSS files, images, other static content for a certain period of time. Here is how to globally configure caching: http://www.sitefinity.com/documentation/installation-and-administration-guide/system-settings/configuring-caching.aspx.

@Andrei. Those extra lines are for setting expiration headers on assets that are not managed by the CMS. Such are JS libraries, CSS, and image files that are not under ~/App_Data and registered in a theme, as well as embedded resources (ScriptResource.axd, and WebResource.axd). So yes you can add them manually.

Best wishes,
Radoslav Georgiev
the Telerik team