New Site Launch + Performance Questions

Topics: Announcements, General
Editor
Aug 1, 2011 at 2:24 PM

I would like to announce the launch of a new site that has been developed on Orchard CMS! http://www.tritondigital.com, is the third iteration of an ongoing project to add Blogs, News, Localization and a lot more functionality to the site. It is based on an Orchard development base that I began about 5 months ago. The site looks great and is utilizing a lot of modules such as Advanced Menu, Culture Picker, Culture Layer, URL Alternates, Blog, Contrib.Contact, Vandelay Meta, Cloud Construct Apple Touch Icon, etc. The client is very happy with it and I think it shows some great features of Orchard.

Since this is the third phase of the site, a lot of architectural changes have been made, Orchard has been upgraded, and most of all I know a lot more than when I originally started development. One question I have is I seem to notice some performance issues with the site. The page loads take about 10 seconds for me, and I would like to get that down to about 5 seconds. I have so many modules and widgets/layers setup it seems like it will be tough to figure out where this performance issue may be. Can anyone recommend a good way to debug this? I would like to see if maybe a bad design decision on my part or a particular module is causing this problem.

 

Thanks!

Aug 1, 2011 at 6:01 PM

Just looked at your site and the homepage looks great!

You appear to have a bad link though. If you go to the bottom center of the page and click on CMS (under Products) you will see what I mean.

Coordinator
Aug 1, 2011 at 8:04 PM

Very nice, but indeed there is a performance problem (even 5seconds would be quite bad). What kind of host is there under this? Do you have the same issues with a local site? What version of Orchard is this running? Are you in full trust? Are you in release mode? How many layers and how many widgets?

A good approach to debugging this would be to use a profiler and see where all this time is being spent.

Editor
Aug 1, 2011 at 8:15 PM

Obtaining the production server configuration now from the hosting provider.

Locally it is not nearly as slow. It is running Orchard v.1.2.41.0. The web.config has debug flag set to false and trust set to <trust level="Medium" originUrl=""/>. There are 45 layers and around 65 widgets. Things were tripled due to the localization, and there are many unique sections which require their own layers.

I am using the Culture Picker, Advanced Menu, Culture Layer, to name a few modules. There are three copies of all the content because it is localized in three languages. EN,FR,ES.

I looked at the Experimental > Profiling module but had no clue on how to use it. Could you describe how to use it or possibly recommend a profiler to use on my staging site to see where we are having problems?

Thanks

Coordinator
Aug 1, 2011 at 8:20 PM

OK, so the first thing you'll want to do is switch to full trust. This will give it a nice boost.

Second, if you suspect widgets and layers, try to disable the widgets module momentarily and see if it makes a difference. Then we can look closer if it does.

When I suggested a profiler, I meant a .NET profiler, which is relatively heavy to set-up and needs to be done on the server. Not sure you'll have that luxury, depending on how much access you have to the host.

Oh, another thing you may want to try on top of all the rest is the second level cache module that was recently submitted to the gallery.

Editor
Aug 1, 2011 at 8:38 PM

So I set the Full Trust option in the web.config. I next disabled the Culture Layer module, which determines alot of what widgets appear on the page. This sped up the pages a ton because there was basically nothing but content rendering. I then removed the culture layer rule in the English Layer so all the widgets re-appeared. Pages slowed down again. Next, I disabled the widgets module and the pages were fast again because no widgets were being rendered.

Do you suggest I enable/disable widgets one by one to see which one may be causing the issue?

Coordinator
Aug 1, 2011 at 8:40 PM

Yes, that would be a good next step but the culture layer thing seems to be a good place to dive into as well... Maybe some request-level caching is in order.

Editor
Aug 1, 2011 at 8:43 PM
Well I enabled the Cache 0.2.2 Module this morning but it did not speed things up. Does that automatically begin Request level caching? I noticed in the Cache Menu page, there were no pages in cache. Maybe I did not enable it all correctly?

On Mon, Aug 1, 2011 at 3:40 PM, bertrandleroy <notifications@codeplex.com> wrote:

From: bertrandleroy

Yes, that would be a good next step but the culture layer thing seems to be a good place to dive into as well... Maybe some request-level caching is in order.

Read the full discussion online.

To add a post to this discussion, reply to this email (orchard@discussions.codeplex.com)

To start a new discussion for this project, email orchard@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com




--
Thanks,

Arra

Coordinator
Aug 1, 2011 at 8:49 PM

Ah, well, I meant adding some caching in the culture layer module, because I'm suspecting that it is doing repeated database access for each layer, on each request. If you added code in there that cached that information at the request level, that would maybe fix the problem. And it would be agood contribution to that module ;)

Now this being said, the cache module is a good thing to enable as well and it is pretty much configuring itself.

I was actually referring to another caching module that you might want to add, but apparently it's not yet on the galler. You can find it here: http://orchard.codeplex.com/discussions/263612

Aug 2, 2011 at 2:40 AM
Edited Aug 2, 2011 at 2:41 AM

Alright Betrand, I can take a hint.  I published my module in the gallery.  Now that I have, do you think you could try to talk Louis or someone into helping me out with my ContentQuery injection issue (mentioned at the end of that other thread)? Pretty please?

Coordinator
Aug 2, 2011 at 2:44 AM

Thanks so much :) I'll do what I can. Do you mind sending me e-mail recapitulating the issue? bleroy at you know where.

Editor
Aug 2, 2011 at 3:24 AM

So I started to remove some widgets in order to isolate the problem. I found that after removing the Advanced Menu widgets the pages sped up. My home page contains 1 Advanced Menu widget for Primary Nav and then 3 Advanced Menu widgets at the bottom for Footer Navigation. After removing them all, my page speed went from 9.37s to 4.48s. My secondary pages which have an extra secondary nav went from 6.56s to 1.54s.

I will need to find a solution for this, and I guess I will have to profile the Advanced Menu module to see where it might be having issues.

Coordinator
Aug 2, 2011 at 3:27 AM

The best case scenario would be for this to end up being a contribution to the advanced menu :) Let us know what you find. The menu does look like something that could use some major caching.

Editor
Aug 2, 2011 at 3:29 AM
Could you recommend a method or application for profiling?

Arra

On Mon, Aug 1, 2011 at 10:27 PM, bertrandleroy <notifications@codeplex.com> wrote:

From: bertrandleroy

The best case scenario would be for this to end up being a contribution to the advanced menu :) Let us know what you find. The menu does look like something that could use some major caching.

Read the full discussion online.

To add a post to this discussion, reply to this email (orchard@discussions.codeplex.com)

To start a new discussion for this project, email orchard@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com




--
Thanks,

Arra

Aug 2, 2011 at 3:34 AM
Edited Aug 2, 2011 at 3:36 AM

Arra - I know the link I provided doesn't work (I don't think the gallery site has updated?), but you can install the module directly from the gallery feed inside orchard (just search for Database Caching).  See if that helps.  It knocked out a decent number of the advance menu queries if I remember correctly.  When bertrand helps me out with my issue, it'll knock out all of them :-).

Aug 2, 2011 at 3:35 AM

As for profiling, it's not free, but I use nhprof (http://nhprof.com/).  Takes a little wiggling to get it to work in orchard, but it's awesome nonetheless.

Editor
Aug 2, 2011 at 4:05 AM

@ldhertert , Seems like the database caching module took about a second off of the load time, but nothing significant enough to show a large improvement. I can probably get away with removing the 3 footer widgets and the one secondary widget, and replace them with static HTML widgets. It will be a pain though. I will try and profile the app and see where the app is being held up in the Advanced Menu module.

Coordinator
Aug 2, 2011 at 5:55 AM

We use JetBrains' DotTrace and DotMemory. They are not free tool, but still fantastic.

Editor
Aug 2, 2011 at 2:11 PM

Thanks for the help guys. I will look into grabbing a profiling tool to use and find any other bottlenecks that may be slowing the site down as well. For now I improved the performance of the homepage from 9.56s to 4.0s and secondary pages at 5.56s to 1.45s. The homepage has some image lists, news lists, and blog items on it so I suspect that is what is taking a little extra time. (Filtering for cultures.)

I sped it up by replacing all my Advanced Menu Widgets with HTML widgets containing the hardcoded HTML. I am using JS to toggle active states, etc. I will look into fixing the Advanced Menu module, but needed to get something to production for this issue ASAP.

Thanks again.

Coordinator
Aug 2, 2011 at 10:25 PM

I'm still surprised that the cache module wouldn't improve things more, in particular on the home page. We might want to verify that it actually works.