In the process of using Tuxedo, you will encounter some of the cases of concurrency requests, such as some billing processing services or day operations before business. At this time, some service will receive a large number of clients, even long-time requests, to Service, and even the entire system is a severe test. In this case, a single server is often difficult to cope, or the performance is not good, we think of load balancing or use Tuxedo's MSSQ (Multi Server, Single Queue). The author is discussed in accordance with the practical system pressure test results in the practice of Tuxedo application development and management configuration.
In the case where there is no load balancing, the client is handled by a server to the client's request, all requests are first put in this Server's queue, and the Server takes out the process one by one. On UNIX systems, Tuxedo uses more queues and also uses shared memory and semaphore, and the associated UNIX system parameters will affect the performance of the system, but this is not within the scope of this article, here it is assumed to have been tuned. The range, please check with Tuxedo About IPC documents.
The Server, which is now processed, for example, the load balanced server UBB configuration is:
BillPay SRVGRP = Group1 SRVID = 1
In the case where a single Server does not meet performance requirements, it considers the load balancing method using Tuxedo.
Method One is to directly enable the relevant Server to change the above configuration to:
BillPay SRVGRP = group1 SRVID = 1 min = 5 max = 10
In this way, when TMBOOT will have min = 5 BillPay start, similar to the following situation:
BillPay 00001.00001 Group1 1 0 0 (iDLE)
BILLPAY 00001.00002 Group1 2 0 0 (IDLE)
(According to this type, a total of 5)
The second column is the queue name of the Server, "." Is GrPno, followed by Srvid, each server has its own queue. Another parameter is the LDBAL of the UBB's * resources segment indicating whether to start load balancing, the default is "N" (not started), you can start by setting it into "Y". It should be noted here that the multiple Server cannot partition when "N" is not indicated. When the main difference is "Y", Tuxedo will find the appropriate Server when receiving the request, when it is received, when it is set to "N", it is always the first available Server. deal with. Through this method, multiple Server can process a large number of concurrent requests, and achieve the purpose of improving performance.
Method 2 is to use MSSQ (Multi Server, Single Queue), as the name suggestions, there are multiple Server, but there is only one queue (request queue). The specific configuration is:
BillPay SRVGRP = group1 SRVID = 1 min = 5 max = 10
RQADDR = "BillPay" replyq = Y
The situation after the startup is as follows: BillPay BillPay Group1 1 0 (IDLE)
BillPay BillPay Group1 2 0 0 (IDLE)
(According to this type, a total of 5)
We found that several BillPay Server associated with the same name-called BillPay, this is the so-called Single Queue.
More than two parameters compared to Direct multi Server, RqAddr is a queue name of these Server shared, is a logical name, you can name, not with other conflicts, replyq is the label of whether to set the return queue, It is strongly recommended when using MSSQ, as this can be separated by request and returning to avoid confusion when multiple Server shared queues. The relevant other parameters are not listed in detail here.
There is no difference in two ways and no load balancing, and the relevant test results will be provided later. First analyze two methods. Methods A plurality of queues can accommodate requests, but these large numbers of requests will have certain strategies, and according to LDBAL settings, this policy itself is also a consumption because each request is Faced with this choice. Because each queue is corresponding to Server, the selection of the queue means that the corresponding server is selected, so a lot of requests are split. Although there is a choice of consumption, additional benefits are also obvious, that is, there are multiple queue available, effectively avoiding the overflow of the request and has a large queue, which occurs in the actual pressure test. When using methods 2, don't make a selection when you put the queue, and then each Server task is to remove the request destination from the queue, considering multiple Server and extracts the queue, so the number of SERVERs when using MSSQ, the official document Recommendation 2-12. And in this case, it is recommended not to set ldbal = y because the MSSQ itself is a method of load balancing based on Single Queue, and the system's policy has no meaning. This method also has a problem. If the number of requests is not fast enough, it is more likely to cause queue overflow than the first method.
Because we can't know some of Tuxedo some specific algorithms and strategies, then use some specific tests to compare. The author has made a trial on a UNIX Oracle Tuxedo8.0 system in one and the actual production system. The test service is a bill query service. Each time according to a batch of ID, query the specific bill from the database, due to They are all actual data and actual services, have certain descriptions, but do not exclude errors caused by some situations. The following is some results of the test, and the actual number of running parts of each server is 10.
First: The number of clients is 1, and the loop calls 100 times.
1. Method 1, ldbal = y or n. As a result, all requests are all handled by one of the server, all of which are free. On this basis, twice cycle calls, the result is still the same.
2. Method 2, ldbal = y OR N. Two of these tests are:
<1> 19, 19, 2, 2, 1, 18, 18, 1, 1, 19
<2> 23, 8, 23, 23, 23, (Other Idle) The above data indicates that the scheduling strategy in two ways is different, and the method is more appropriate in the case of a single client cycle.
Second: The number of clients is 50, each cycle 80 times, statistical execution time.
1. Use Single Server. The processing time of the two tests is 219S and 196S, respectively.
2. LDBAL = Y method one: three test times: 63S, 79S, 69S
3. Ldbal = n method one: three test times: 74S, 79S, 85S
4. LDBAL = Y method 2: three test times: 74S, 73S, 77S
5. LDBAL = n Method 2: Three test times: 78S, 76S, 75S
Through the above data, it can be seen whether or the load balance can be used to get better performance compared to a large number of requests compared with the single server. But at the same time, the total time difference of the last four cases is not large, considering some actual errors, it is difficult to determine which better.
Through the previous analysis, consult the relevant document, it is recommended to use two ways: multiple Server, do not have MSSQ, set ldbal = y; use MSSQ, set ldbal = N. Of course, in the use of Tuxedo's application, it is better to say which way is better. It can only be analyzed according to specific situations, and the actual pressure test is selected, and this and the specific Server characteristics are also related of.
The above is some of the results of some personal analysis and testing, and it is written out and everyone to discuss, and I hope that everyone will ask yourself and discuss it.
2003-4-24,
Guangzhou
