This project is read-only.

Summary from Orchard Performance Group - Day 2 of Orchard Harvest

Topics: Announcements
Jun 15, 2013 at 4:14 PM
Edited Jun 16, 2013 at 10:59 AM
I thought I'd sumamrise what I understood from the group discussing performance on Friday. I'm sure that Sebastian can add or correct any content. If there is good content in this thread I'll try to turn it into a blog post

File Watchers

Orchard makes significant use of (.NET) file-watchers when monitoring for changes. Pretty much ever file under your sign will be watched (theme files, .cs files, csproj, module txt files and so on).

In a production environment there are the following recommendations
  1. build using the "precompiled" target
  2. Ensure that you do not have source code (.cs) files on your production server (a normal publishing scenario, but Orchards dynamic nature encourages you to deploy these .cs files)
  3. In 1.7 you can turn on/off all the file watchers via the host.config file If you build with precompiled this will automatically happen (Sebastian???)
In most production environments, the items that file-watchers are observing will not change (it is generally not recommended to allow modules to be uploaded to the production environment for example)


In general, for every route you add to your site, the longer the router will take to resolve the correct action (obvious in a way, but a subtle point). Large numbers of routes can lead to performance drops, particularly as the MVC implementation of routing is not necessarily the fastest. The same statement can be used to cover any URL-rewriting - having hundreds of routes listed for url re-write in IIS could be extremely detrimental (Brett - would love to hear any follow up results on this topic)


There are several forms of caching available, each with different purpose (Sebastian - please correct me if I misrepresent any of these)
  1. Sys.Cache - standard Orchard caching of database objects. There is no reason not to have this on
  2. Using CacheManager wthin driver code. Makes use of standard ASP.NET caching. Simple to use, but has the following contraints; works only on a single node and limited in the expiry mechanisms
  3. Contrib.Cache (this is page output caching???)
  4. Orchard.Caching (planned to released with core modules of 1.7, currently available via . This provides a caching interface suitable for use with MemCache or AppFabric/Azure implementations. (Am I right that there is an existing appfabric implementation?). Key difference to the default object caching is that it is available across nodes, and therefore more suitable for load balanced situations
Not directly mentioned in this session, but clear from the case studies presented by Brett Morrison and Sam Goldenbaum is that page caching is only viable when you remove dynamic elements from server load, and instead ajax-load them in after page load is complete. A key technique being used is Orchards new web-api support, coupled with backbone.js (And there is an Orchard.Backbone module that assists with access to content

SQL Server

There was a brief discussion on SQL Server (an area I'm at least pretty confident on). Other than the obvious, that SQL CE and (to a lesser extent) SQL Express are not as suitable for enterprise production, we discussed some of the basic considerations of SQL Server
  • SQL Servers tend to get limited by their IOPS potential. In summary, this is about having fast disks, and splitting data fiiles/partitions/transaction logs/OS correctly across them. This is particularly key in VM environments as even if the VMS appear to have separate logical drives, they may actually be pointing at a single LUN/disk array behind this.
  • SQL 2008 onwards takes as much memory as you can give it. It is not necessarily a sign of a memory issue if your SQL server is consuming all server memory
  • Orchard provides no default indexes for sites. This is not unexpected, because required indexes can be varied depending on the usage of your site. A good recommendation is to use SQL profiler to record a trace for an extended period (say several hours during typical usage) and to provide this trace to the index tuning wizard. Mostly this wizard is extremely good at recommending indexes.
  • Something that was not said in the meeting, but I think it is worth adding is that you should ensure that SQL Server Statistics/Indexes are regularly updated via maintenance plans. This allows SQLs query planner to make effective queries.

Other snippets

  • Running your app in 32 bit is bizzarely still the recommended route. Running in 32bit takes half the memory and is not as prone to memory leaks as 64bit currently. (Sebastian, would you be able to clarify this too, as I was not sure if you meant windows, IIS, app pools or compiling for x64...)
  • Orchard "first load" is around 16 seconds. 8 of these are ASP.NETs "JIT" activities. This issue has already been reviewed with the ASP.NET team and it appears that this cannot be improved upon.
I would be delighted if anyone who was in this session and remembers further elements of the discussion would please post below. It was a pleasure meeting you all.
Jun 15, 2013 at 4:27 PM
for chache, what is new Orchard.OutputCache for?
thanks andy
Jun 15, 2013 at 5:44 PM
as mentioned above - the key difference is that it works across load balanced nodes. Invalidating cache items on one server will invalid it across all servers in the farm. As such, this method of caching is much better suited to caching your domain object data.
Jun 16, 2013 at 12:37 AM
Thanks Paul, great write up.

Routing: Definitely sounds like we need to move ALL of our rewrite rules from the rewrite module to Web.Config. This way IIS will route the request before it goes through the .NET and Orchard pipelines. Better to let IIS handle it. An open issue is if it's possible to have > 1 external file to keep your rewrite rules in. I've checked before and was unable to have > 1 external .config file. I'll post the question on the IIS forums.

Cache: Definitely want to see more people using Orchard.Caching, and Orchard.Caching.* (Providers). There is an AppFabric implementation, and you can even choose your serialization engine: We are also releasing shortly a module called: NHibernate over Memcached, which is effectively a shared SysCache.

Good stuff during that meeting. I'm looking forward to seeing what else the community brings up as topics for further discussion.
Jun 16, 2013 at 10:59 AM
updated my post to include sections on SQL Server, which we also touched on.