A formal performance tuning method--based on the waiting tuning

The performance tuning of Enterprise Java applications is a daunting, sometimes futile task, caused by the complexity of modern applications and the lack of formal tuning methods. Modern enterprise applications are quite different from those applied ten years ago, and these applications now support multiple inputs, multiple outputs, complex frameworks, and business processing engines. and 10 years ago, web-based enterprise applications were simply getting input from a Web browser, then interacting with the database or legacy system, and finally returning the output to the browser (HTML). The input information can now come from an HTML browser, a rich client, a mobile device, or a network service that spans servlets or portal containers running under different architectures, which in turn may invoke enterprise beans, external Web services, or delegate processing to the business rules engine. Each of these components can interact with content management systems, cache tiers, numerous databases, and legacy systems. The output information is usually saved as a presentation layer, and then translated into HTML, XML, WML, or any other format required by any client. Modern applications contain more moving parts and "black boxes" than in the past, which presents a huge challenge to performance tuning.

In addition to increased complexity, performance tuning techniques are more artistic than scientific, because most performance tuning guides focus on performance metrics, sometimes obscure, and may affect the user experience. This article attempts to turn performance tuning activities into a "scientific" category of behavior, providing a reusable way of focusing on the user experience, using the "wait point" (i.e., the part of the application that causes a request to wait) to analyze the application architecture. In summary, the wait based tuning approach allows performance engineers to quickly implement measurable performance improvements by optimizing the user experience.

Performance Tuning Process

Before detailing a method based on wait tuning and wait point analysis, this section begins with an overview of the effective performance tuning process. Performance tuning can be simply summed up in four steps:

Load test

Container tuning

Application Tuning

Iterations

Like most computer science, performance tuning is an iterative process. First, create an appropriate load test that includes a balanced, representative service request that can be satisfied by the container tuning practice. As the container is constantly tuned and the test pressure increases, the bottleneck of the application becomes apparent. As the application bottleneck is positioned and resolved, the application behavior will change, which requires the container to be tuned again. The iterative process between the container and the application continues until the performance reaches acceptable conditions (or until the project has expired that it must be published).

Load test method

The prerequisite to starting a performance tuning practice is to create a complete set of appropriate load test sets. Each load test must meet the following two points:

Representative, must reflect the end user's business scenario (or expected scenario)

Equilibrium must conform to the proportional distribution of the end user's different behavior

That is, the load must be able to simulate the user action in terms of the actual operating ratio of the end user. To illustrate the importance of balancing end user actions, consider the following example: In the insurance claims department, the employee performs the following actions:

User eight o'clock in the morning login system.

An average of five claim requests were processed per person in the morning.

About 80% of users forget to log out of their accounts before eating, causing the session to expire.

After lunch, the user logs on to the system again.

An average of five claims were processed per person in the afternoon.

Generate two reports before work.

80% of users go home and log out of their accounts before returning.

This example is a simplified version of a real application, but it is sufficient to create a balance in these service requests. The balance shown in this scenario is: Two landings, 10 claims processing, two reports and one cancellation.

What if the load generator distributes the pressure evenly across the different service requests? In this case, the user login and logoff feature receives the same load as the processing claim request. If it is 1000 concurrent users, the login function will quickly crash, causing the enterprise to invest in building a landing component that can handle this load, but in fact this load does not happen at all. Worse, in this case, because the biggest bottleneck seems to be on the landing function, tuning efforts focus on the feature, ignoring the claims processing function. In short, an unbalanced load can cause the tuning process to focus incorrectly on components that support the load that will never happen, rather than the ones that really need tuning!

Determining whether a load is a balanced and representative standard for applications is different for testing an existing application (or a new version) or a new application.