Go WebSphere Pool resource tuning-thread pool, connection pool, and ORB

WebSphere Pool resource tuning-thread pool, connection pool, and ORB

From: https://www.ibm.com/developerworks/cn/websphere/library/techarticles/1106_zhuxl_websphereenhancement/1106_ Zhuxl_websphereenhancement.html

IBM WebSphere Application Server (was) can support an increasing number of applications that have their own unique features, requirements, and services. Just as no two applications are using the application server in exactly the same way, we cannot provide the best performance for any two different applications through a set of tuning parameters. This article focuses on the tuning of the various pool resources in the WebSphere server, focusing on the role of the thread pool, connection pooling and ORB, and the basic guidelines for tuning, in this article, readers will have a more precise grasp of the was tuning, especially the understanding of the various pool resource configurations. This allows you to use WebSphere servers more efficiently.

0 Reviews

Zhu Xiu Lei, software engineer, IBM

June 13, 2011

• Content

Free Download: IBM? Websphere? Application Server Trial Version
Download more IBM Software trials and join the IBM software download and technology Exchange Group to participate in online communication.

Overview of WebSphere Performance Optimizations

What is causing the performance problem? Or how to improve the performance of the system? This is the problem we often encounter in the development and maintenance of the system, but these two questions are difficult to answer. As shown, performance problems may occur in various parts of the system, when performance problems come out, it is difficult to locate the bottleneck in the performance immediately, even if the performance bottlenecks found, in the tuning should also consider the overall system environment, from the context of the analysis, to determine the tuning strategy; the existence of one or more "short boards" in the system, Can make the system unable to achieve the design-time goals, the expected performance gains.

In this article, we focus on tuning the various pool resources in WebSphere, including the thread pool, database connection pool, and the ORB's connection number tuning. Pool is one of the most common concepts that are involved in WebSphere. From the network, Web servers, web containers, EJB containers, to the data source, each link is a thread pool, connection pool shadow. These pool resources are connected from top to bottom, forming a queue for access and response. In WebSphere tuning, if these pool resources can be properly configured, the efficiency of the whole system can be improved to a great extent.

Figure 1. Performance problems occurred in was and the operating system in various aspects of was poor performance and solutions

The system performance difference generally has the following two kinds of very obvious manifestation, the first kind is the CPU usage is not high, the user feels the transaction response time is very long, the second kind is the CPU usage is very high, the user feels the transaction response time is very long. In the first case, it can be concluded that the bottleneck is caused by a small part of the system, causing all requests to wait. For example, the number of thread pools is too small, causing all requests to be queued for entry into the thread pool, because there are no available threads to use, so this transaction request has been queued, resulting in a long transaction response time. If the database connection pool is too small, it will behave the same way. For the second case, it is more complex. One of the possible sources is insufficient hardware resources. The second source is that many large objects are produced in the application system. The third reason is that there is a problem with the program algorithm. The solution is as follows: Analyze the running environment with a performance analyzer, such as RAD or Jprofiler, and analyze which classes and even which functions consume so much of the CPU and find the corresponding solution.

Was performance tuning there are no shortcuts and magic, because each application has its own unique features and resource requirements, and they use the resources of was also in a variety of ways, each set of tuning parameters and policies only apply to the current system environment, In a real-world system environment, it is not easy to migrate one tuning strategy intact to another system environment, often without the desired tuning purpose, and possibly by more performance bottlenecks.

Back to top of page

WebSphere System Queue Introduction and tuning

Was is made up of a series of interacting components that must be properly tuned to meet the requirements of the customer's application for system performance. These adjustments and tuning will help the system achieve maximum throughput and maximum usage efficiency.

WebSphere Queueing Network

When a client makes a request, the request goes from the network side to the various components of the Wehsphere server, which are queued to use the server resources in each component or wait for the next component to be further processed by the server, and the requests in each component form the request queue. The components, in turn, are enough to be a WebSphere queueing network. As shown, the queued network includes the Internet, Web servers, web containers, EJB containers, connection pool queues on the database side, and so on. Each component in the WebSphere queue is resource-dependent, and the average service time for the request depends on the maximum number of concurrent times per component in the server queue at the same time.

Figure 2. WebSphere Queueing Network

Conservative queues and open queues

Most of the queues that make up the WebSphere queueing network belong to the conservative queue. For conservative queues, we can set some parameters to limit the maximum number of concurrent requests that are processed in the queue, whereas the development queue has no such limitations. In contrast to open queues, the advantage of conservative queues is that system resources can be effectively managed and utilized to avoid system crashes due to resource exhaustion. For example, in a Web container, assuming that the average processing of a servlet request is to create an object of 10M size, if we set its maximum number of connections to be 100, then the maximum amount of memory consumed by the Web container can be controlled around 1G. Therefore, conservative queues enable system administrators to manage system applications more effectively.

A user request in a conservative queue has two states, the active state and the wait state, respectively. When the request is active, it indicates that the request is being processed by the server, and when the request is in a waiting state, it indicates that the request has not been processed, but is waiting to be activated in order to be able to use the server resource. A pending request is activated only if an active request is processed, or the request waits until the server time-out throws an exception, and if this occurs, the server needs to be system-optimized.

In a queue network of WebSphere servers, Web servers, Web containers, and database connection pools belong to a conservative queue. The EJB container inherits the queue characteristics of the object request broker (ORB), which belongs to the open queue.

Queue tuning and provisioning in WebSphere

In WebSphere, we tune and set their queues primarily by the maximum and minimum number of two parameters, and then we give a basic guideline for WebSphere queue tuning. Readers can refer to this criterion in later tuning, and then combine their actual system environment to perform the queue tuning.

The "funnel" principle

The first principle of is tuning is the funnel principle. In general, it is better to allow customers to wait on the network for requests that are not processed in time, rather than waiting for them to wait on the WebSphere server. Settings make it possible to enter the queued network of was only if a request is being processed by the server, which can improve the stability of the server rather than causing resource exhaustion when a large number of requests suddenly enter was. To implement this principle, the downstream component, the maximum number of concurrent processing requests should be less than the maximum number of concurrent upstream components. As shown, only requests that can be processed enter the corresponding component to be processed, and other requests that are larger than the number of concurrent components of that component are queued and waiting for the server to accept processing.

Figure 3. Upstream Queuing

In the example, we can see that in the WebSphere queueing network, the number of concurrent requests processed from the top-down queue is getting smaller. When 200 client requests reach the Web server, because the Web server set its own maximum number of concurrent is 75, so the remaining 125 customer requests can only be persisted in the network queued to be processed by the Web server, when the 75 requests were processed by the Web server, where 25 Still remain queued in the Web server, and the remaining 50 requests go into the Web container for further processing, until the last 25 requests arrive at the last database end, when the request is processed. In this system, each component is fully working, and there is no resource waste due to waiting for a request, because at any one point there is a small number of requests in each queue waiting to be processed by the next component. Because a large number of requests are blocked from the outside of the WebSphere Server (network), the various components of WebSphere do not cause resource exhaustion due to the simultaneous arrival of a large number of requests, which increases the stability of the system.

Drawing the throughput rate curve

As described above, one of the most important guidelines for tuning WebSphere Server pool resources, let's describe how to tune settings based on this guideline and in combination with the user's actual system environment. First we need to draw the system at run time throughput curve, to complete the curve, we need to prepare a test case, and then the system to run, our goal is to maximize the potential of the system, that is, the system runs to achieve a resource utilization of the saturation point. The most representative new feature of the system running to saturation point is that CPU utilization is close to 100%.

At the beginning of running the test case, we set all queue concurrency in the WebSphere queueing network to a larger value, and the values for each queue are set to be equal. Make sure that this setting allows your system to achieve maximum processing power at run time. For example, set the maximum number of concurrent queues for each queue in a queued network to 100.

Now we start a series of tests to plot the throughput curve based on the test data. After each test, increase the number of user concurrency, iterative testing, for example: Set the number of user concurrency to a set of values for a series of tests (1,5,10,25,50,100,150,200 ...), after each test, record the throughput rate and response time of the system, You get a similar throughput curve.

Figure 4. Throughput Rate Curve

Throughput is the concurrency at which WebSphere servers process user requests at the same time, reacting to the ability of WebSphere to process concurrent requests. From this we can see that the curve can be divided into three stages, in the first stage, that is, a phase, when the number of concurrent is less, throughput rate with the increase in the number of concurrent increase. Because at this time, the number of concurrency is small, there are almost no requests queued in the queue, every time a request arrives can be processed immediately, with the increase in concurrency, in a moment, the queuing situation began to appear, the throughput curve growth is slow, until the saturation point of the system processing capacity is reached, This is when the system's performance bottlenecks occur. The most representative system bottleneck is that at saturation point, when the system CPU utilization is nearly 100%, we can improve the performance of the whole system simply by switching to a higher performance CPU. After the saturation point, the throughput curve enters the second stage B, and as the number of concurrent increases, the throughput does not increase, but is maintained at a stable level. However, the client's perception of the server response time will increase with the number of concurrent increases, then because a lot of requests queued in the queue, and not in a timely manner by the server processing. At this point, the concurrent number continues to increase, will enter the third phase of C, then, with the increase in concurrency, the throughput rate will drop sharply, when a component in the system is overloaded, resulting in resources have been exhausted.

In the process of drawing the curve, we need to pay attention to a problem, if the saturation point at the time of the system's CUP utilization is close to 100%, then we can make further tuning settings, if the CPU utilization is not reached 100%, then the system running in the application has a problem, Which is the performance bottleneck. For example, your application may create a lot of large objects, leading to frequent GC in JAVA, a lot of system resources and performance bottlenecks, for performance bottlenecks, we need to carefully examine the program source code, identify the problem, and then modify the troubleshooting, to eliminate the system bottlenecks caused by the application. There are many ways to find the bottleneck of performance system, it is not the focus of this article, readers can refer to other information for troubleshooting.

Queue Initial Adjustment

The number of user concurrency at the saturation point of the throughput curve is the maximum number of concurrent applications that can be processed by the system, which is also the dividing line between phase A and phase B. This value will be a benchmark for us to adjust the queue size. As shown in the saturation point, when the concurrency is 50, we select 48来 as the base value for adjusting the queue because the throughput and response times are optimal at this point, which is called the maximum number of concurrent requests that the program can handle. As we described earlier, the ideal scenario is to ensure that a large number of waiting requests are in the network, not the WebSphere server, so by referring to the "funnel" principle, we can set the maximum number of concurrency for each component in the WebSphere server as follows: Web server, 75,web Container 50, database connection pool 45. We then perform a series of tests to fine-tune these values to make the system perform optimally.

Adjust the queue according to the actual application

It is not enough to tune was just according to the criteria above, and we should also adjust the size of each queue based on the application's usage environment and access model. Not all requests will go from the previous queue to the next queue, for example, some requests may be returned to the client after being processed by the Web server, because these users simply want to request some static page content, we can set the Web server queue value Larger, we will be the Web The server is set to 75 that's the case, and for example, if most of the requests in an application require complex and time-consuming database operations, then we should consider increasing the queue value size of both the database connection pool and the Web container. Therefore, in our actual tuning, we must combine the specific application to determine the appropriate value, and in the process of continuous adjustment, monitoring the use of CPU and memory, to avoid the situation of system resource exhaustion.

Back to top of page

Best practices for tuning WebSphere pool resources

We give some suggestions for WebSphere pool resource tuning here, but the real fit is the actual size, and tuning is a gradual process that requires constant trial and modification to achieve the best performance required for system design.

ORB Tuning

When configuring the ORB thread pool, you need to understand the EJB client's access patterns to the app. For example, if you have only a few EJB calls in a servlet and the time for each method call is relatively short, you should adjust the value of the ORB thread pool to be less than the maximum number of concurrent Web containers.

Figure 5. EJB invocation Pattern

The number of servlets that call the EJB concurrently and the duration of each method call is the two basis for us to adjust the size of the ORB thread pool. For example, there are two scenarios where EJB is invoked from a servlet in was. In the first scenario, the servlet mainly makes remote calls with very short durations, and the servlet can reuse the ORB threads that already exist. In this case, the orb thread pool can be set up small, for example, as long as the WEB is set to the maximum concurrency of one half of the line, in the second scenario, the long duration of the EJB call will occupy the ORB connection for a long time, so the connection is very small opportunity to reuse, so in this scenario, it is best to the ORB The size of the thread pool is set equal to or greater than the maximum concurrency of the Web container. You can configure the ORB thread pool using the was management console, located in Application servers > AppServer name > Thread pools > ORB.thread.pool

Web container thread pool

In general, cpu,5 to 10 threads per server will provide the best throughput. In addition, we can also use the TPV from was to help us set up the Web container thread pool. Perform a stress test on the system, maintain a certain load, observe the configuration of the PercentMaxed ActiveCount 的值，PercentMaxed 表示所有线程被使用的平均百分比，如果该值较大，那么就应该增大线程池的值；ActiveCount 表示被激活的线程个数，如果该值远小于当前线程池的大小，那么可以考虑减小线程池的值。可以 Web container thread pool in the TPV and use the was management console, located in Application servers > AppServer name > Th Read Pools > Webcontainer

Database Connection Pool

When we connect to any database, the initialization of the database connection is a very resource-intensive operation, so when performance problems arise, simply increasing the database connection pool often does not improve performance. It is common practice to first increase the size of the database connection pool by one time to see if performance issues can be resolved and, if possible, to progressively reduce the value of the database connection pool to find performance bottlenecks and the size of the connection pool when optimal performance is achieved. In general, the value of the database connection pool is smaller than the value of the WEB container thread pool is the better choice.

In a real world, we can use TPV to monitor database connection pool usage to adjust the size of the database connection pool to determine the optimal tuning strategy. You can find the answers from the following monitoring values of the TPV.

Table 1. TPV Monitoring List

Monitoring Value Name	Description	Tuning Strategy
Poosize	The size of the connection pool	The poosize will increase as new connections are established and will decrease as the connection is destroyed; a maximum value should be set for the connection pool.
Percentused	Percentage of connection pool threads being used	If the value is very small for a long time, then you should adjust the small poosize, the other should increase.
Waitingthreadcount	Number of threads waiting to establish database connections per unit of time	The best performance of the system is that the value is always kept in a very small number, and if the value is large, the system needs to be tuned
Percentmaxed	Percentage of time that all connections in the database have been used	Make sure that this value does not reach 100% for a long time, and if so, you should consider increasing the poosize value

You can configure database connection pooling using the was management console, located in JDBC providers > Provider name > Data sources > Data source name > Connection poo Ls

Back to top of page

Conclusion

In this paper, we discuss the concept and tuning of pool resources in WebSphere Server in detail, and on the basis of introducing the WebSphere Queueing Network, this paper expounds how to allocate pool resources in the actual production environment. By reading this article, readers can master the general criteria of WebSphere performance tuning, and can master some techniques and methods of performance optimization.

Go WebSphere Pool resource tuning-thread pool, connection pool, and ORB