Application performance optimization of e-commerce based on WebSphere Commerce (5) Parameter optimization suggestions

Parameter optimization Suggestions

WebSphere Commerce is a large e-business application developed based on a WebSphere application server. After the first successful installation of the WebSphere Commerce application, Setup has initialized the key parameters on the server. This set of default values is a set of initialized parameter values that are summarized by the WebSphere Commerce Test team after repeated tests. It is recommended that the maintainer test the set of defaults as an initial value to compare the gap between the test results and the expected value, so that some of the parameters of the application server are planned to be optimized. If the production environment you are maintaining is working properly and your system performance is up to expectations, we do not recommend that you optimize your existing environment.

In fact, the tuning itself does not have an optimal solution. Whether the system can meet the customer's needs and find and solve the hidden trouble of the system as much as possible depends largely on the experience of the maintenance personnel. The production environment is not allowed to do experiments, so it is necessary to perform full and sufficient testing on the test environment. In addition, there are differences in the scale of production environment and test environment, and the applicability of parameters should be considered when setting parameters.

Figure 1. The life cycle of performance tuning

The optimization principle of WebSphere Commerce parameters

WebSphere Commerce is a database-intensive application, and most JSP and Servlet requests require access to the backend database, while multiple tasks are running in the system background. Therefore, it does not fully satisfy the hypothetical conditions of the funnel model. The principle of funnel model can be used for reference in the process of parameter tuning, but some adjustments should be made to specific parts.

Figure 2. Parameter tuning model for database-intensive applications

In a particular test environment, suppose that 200 concurrent users reach the Web server at the same time, the Web server has concurrent processing capacity of 75, the Application Server Web container connection pool has a value of 50, then the request from the Web container to the database connection pool is set to 61, for the Webspher E Commerce Here you need to consider not only the number of requests processed by the Web container, but also the need to reserve a portion of the resources to meet background work, including: 1. Background plan work 2. Admin Login Admin Console operation 3. Process data copy (prop).

* Database connection Pool size = Web Server forward client request + Background plan work (Scheduler job) + database connection request generated by administrator connecting to the backend database-number of connections required to process data prop requests

The above example shows that the ratio between the size of the WEB container and the database connection pool is adjusted to suit the needs of the specific application, and the funnel model cannot be applied blindly.

The basic principle of parameter tuning

Before you decide to make parameter tuning, first of all, we need to make a detailed tuning plan, clear the goal of tuning, and then according to the system monitoring results, to identify possible impact on the system performance, try to adjust only one parameter per system, monitoring system performance indicators changes, according to the system monitoring results, Plan to make further adjustments. The most important principle in parameter tuning is that it is best to adjust only one parameter at a time.

Figure 3. Parameter Tuning flowchart