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 Lucene 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 Ucommerce comes with Lucene out of the box. This cannot be scaled out. To solve this requirement we introduced Elastic Search which can help you scale the catalogs APIs of Ucommerce to multiple instances read more here.
This article helps you to get started with Elastic Search on Ucommerce.
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 is important to pick the one that fits your needs and you are familiar with.
In the following open-source repository you will find an example on how to set up and use Redis for the 2nd level cache.
Other things to consider
Most load balance environments can be configured with sticky sessions ensuring that all the requests from a user always hit 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.