Using Ucommerce in a load balance environment

Ucommerce works out of the box in a single web server environment. If performance is a problem, scaling up is an easy alternative to scaling out.

Ucommerce uses SQL Server and RavenDB for storage and NHibernate Caching for an in-memory state. When scaling out all 3 needs to be taken into consideration.

Avoid Sharing Resources

If the web server and the SQL server is running on the same machine, split them into 2 different machines so they don't compete for resources. The only change needed is the connection string in web.config.

By default, RavenDB runs in embedded mode on the web server. Move RavenDB to its own machine so they don't compete for resources. Change the IRavenDbStoreProvider as described here Run RavenDB as an IIS application Don't forget to set the URL for the new RavenDB instance in the component configuration.

Simplest Scenario

Ucommerce mainly caches Products and related information (Orders, in particular, are NOT cached). If the cached information is updated infrequently, from a nightly import or similar, manual invalidating the cache on each of the web servers would make it work. It could be as simple as creating a Web Services endpoint, that calls ICacheProvider.ClearCache(). The import script could call each of the web servers after the product import is complete. A more complex solution could be made with events and queues to ensure that the web servers clear the cache.

Using a Distributed Cache

If Products and other cached data are changed more frequently, using a distributed cache is a better (and more complex) solution.

NHibernate Cache uses a provider-based model, and the default SysCache provider can be swapped out with another. Alternatively, since SysCache uses ASP.NET Cache, the provider for ASP.NET Cache can also be changed.

The important part is that the Cache is distributed (accessible from all the web servers) so that they share a single common state. Popular choices are MemCached, Reddis and NCache, but it's important to pick one that fits your needs and you are familiar with.

Other things to consider

Most load balance environments can be configured with sticky sessions ensuring all request from a user always hits the same web server. This removes much of the complexity of having multiple web servers.

If sticky sessions are not used, make sure all web servers share the same machine key for cookie encryption. Any usage of ASP.NET Sessions, should use a provider that shares a single common state.