WebSphere Commerce considerations
Surprisingly, WebSphere Commerce by itself does not have too many performance tuning knobs. It makes a lot of sense if you treat WebSphere Commerce just like a J2EE application that consists of business logic and relies on WebSphere Application Server to provide the core function to make WebSphere Commerce performs well.
Application Server Dynamic Caching
Cache dynamic content is one of the most important aspects to improve WebSphere Commerce performance. It improves both response time and throughput while reducing system loads. As a result, the site has better performance and infrastructure costs can be reduced.
Since the page layout design and the access pattern of each Web site is so different, Application Server's Dynamic Caching configuration file needs to be customized and configured differently in order to maximize the benefit of dynamic caching as much as possible.
All our starter stores come with a default dynamic cache configuration file which consist of some basic rules to cache some obvious pages (that is, Product Display). These rules are probably a good starting point to understand the potential of dynamic cache, but are probably not sufficient to make the store operate in the most efficient way.
Additional caching rules are being used for the load simulation tests.
HTTPS/SSL
HTTPS protocol needs to be used when secure transmission between the HTTP Server and the browser is required; for example, if a user ID and password is being entered through the browser. The HTTPS protocol will flow HTTP Traffic over the TCP/IP Secure Sockets Layer (SSL), encrypting all traffic between the client and the Web server. There is a performance impact on the Web server since it needs to handle the following additional workload:
- Computation of encryption keys
- Overhead on key negotiation between the server and the client
- Encryption and decryption of the secure content as it is being transferred.
The CPU overhead is determined by the size of the encryption key and the size of the request that is being sent and received between the Web server and the client.
There is a trade-off between performance (from CPU utilization) and security/privacy. During the design of the Web site, each page should be carefully evaluated to see whether encryption is needed or not. Generally speaking, a B2B site uses more HTTPS/SSL as compared to a B2C site.
Trace and logging
WebSphere Commerce uses the WebSphere Application Server tracing and logging infrastructure to provide diagnostic information. This information is very helpful to diagnose problems, but unnecessary tracing adds load to the system from a disk I/O perspective. The best practice is to only log errors and potentially dedicate an independent hard disk to store the logs.
The following steps describe how to turn off all the tracing:
- Open the WebSphere Application Server administrative console.
- Click Troubleshooting > Logs and Traces in the console navigation tree.
- Click the WebSphere Commerce Server.
- Click Diagnostic Trace.
- Clear the Enable Log check box.
- Save the changes and exit.
Use the latest fix pack
Use the WebSphere Commerce latest service pack, eliminate the possibility of encountering performance defects that have been identified and fixed. Also refer to the WebSphere Commerce support site for the latest updates at the following URL: http://www.ibm.com/software/genservers/commerce/support/