Tuning Considerations for WC Sites


This quick blog post explores some basic things clients and partners can do to ensure that WC Sites performs well.

Main Article

Sites engineering has recently provided some insights into common-sense best-practices when it comes to deploying WC Sites on modern hardware. Below is a quick high-level summary of some issues that many clients and partners often get wrong in the field. It also serves as a first-level checklist when diagnosing performance problems with WC Sites 11.g and higher.

Specify more CPUs instead of more cores

For servlet-based applications (of which WC Sites clearly is), the current crop of appservers (including Weblogic) don’t scale linearly when adding more cores. They do however scale mostly linearly when you add more CPUs. Thus you can best advise your client during the procurement phase¬†to specify hardware that has more CPUs/fewer cores instead of fewer CPUs/more cores.

For example: A 4-CPU, 4-core/per core box will generally perform significantly better than a 1-CPU/16-core box even though the total # of cores is the same (all other things being equal).

Use Hotspot, not JRockit

Sites makes extensive use of ehCache for its various cached objects, many of which take the form of hashtables. JRockit exhibits bottlenecks with regard to hashtables (as opposed to concurrent hashtables) especially under high load. In particular, JRockit has problems keeping such non-concurrent hash tables synchronized in a performant manner. Thus, never use JRockit with WC Sites even if it came installed by default on your appserver (e.g. Exalogic v2)

Use Garbage First (G1) Garbage Collection

While it is true that specifying G1 garbage collection will have a slight negative effect on overall peak performance, it will smooth out those pesky “troughs” which will lead to overall better systemic performance and scalability.

Start with 16Gb HEAP

WC Sites makes extensive use of ehCache to store all manner of cached objects: e.g. asset cache, resultsets, page/pagelet cache, co-resident Satellite Server cache objects, etc. Since the number of objects is a large multiplier of the total number of assets and pagelets in your system, it behooves you to keep everything in memory as much as possible and never let the cache spill over to disk. These days, 16Gb is a safe bet and allows even fairly large sites to remain in memory. The days of 1Gb HEAPs are long over.


One of the biggest issues with Virtualization tends to be disk IO — as such, engineering strongly suggests the use of SSD drives to back each VM. Additionally, since most VMs host applications that need access to http or db access, having only a single shared NIC represents an obvious bottleneck. Be sure to increase the number of NICs appropriately when deploying many VMs on the same hardware. It is not uncommon for delivery hardware to be I/O bound due to these common oversights.

Remote Satellite Server

Remote Satellite + “stale cache” mode is recommended (but adds more complexity to testing). See the WC Sites Admin Guide for more information.





Add Your Comment