|
Measures reported by PepAppBBDetailTest
When any Tuxedo application server domain is booted, the first process to be started is the Bulletin Board Liaison process, called BBL. This process is the heart of the application server. It reads the configuration of the domain from a binary configuration file, which in a PeopleSoft domain is called PSTUXCFG. The BBL then establishes a shared memory segment, referred to as the Bulletin Board (BB) or Management Information Base (MIB), some message queues (determined by the specifications set out in the configuration file), and two semaphores. The Bulletin Board holds all the information about the rest of the application server domain including servers, services and their loads and priorities, clients and transactions. It is used as a form of database by the application server processes to determine how they should behave.
By monitoring how requests to a domain are utilizing the server processes, services, and interfaces registered with the Bulletin Board, administrators can ascertain the load on the domain, and whether the domain has been sized right to handle the load. This is exactly what the PepAppBBDetailTest helps administrators achieve.
This test reports the current configuration of the domain by reading the bulletin board. In addition, the test also keeps an eye on the usage of the server processes, services, and interfaces that the domain has been configured with, and proactively alerts administrators to probable processing bottlenecks in the domain, along with accurate pointers to the cause of the bottleneck - is it because the domain does not have enough server processes? services? Or interfaces? Based on the test's findings, administrators can then proceed to reconfigure the domain (if required) to ensure rapid processing of requests.
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Max_server_count |
Indicates the total number of server processes registered with the bulletin board. |
Number |
A server process is an executable code that receives and processes incoming transaction requests. The number of server processes of each type is configurable and typically varies within a domain, depending on the requirements of your application or the main purpose of the domain. To gauge the adequacy of the server process configuration, you need to use the current_server_count and Free_servers measures.
If the current_server_count count is very high and the percentage of Free_servers is low, it implies that the load on the domain is high, but the domain has not been configured with sufficient server processes to handle the load. If the percentage of free server processes is allowed to dip further, request queues on the domain wll only grow longer, delaying request processing or even bringing it to a standstill. To avoid such adversities, you have to probe deeper to identify the server process types that are in demand and configure more server processes of that type in the domain.
|
| current_server_count |
Indicates the number of server processes that are actively processing requests. |
Number |
| Free_servers |
Indicates the percentage of server processes that are currently idle. |
Percent |
| Max_services_count |
Indicates the total number of services registered with the bulletin board. |
Number |
The server process carries out a request by making calls to a service, such as MgrGetObject. The server process waits for the service to complete, then returns information to the device that initiated the request, such as a browser.
A high value for the Current_services_count measure indicates that many services are in use, which in turn implies that the load on the domain is high. If the percentage of Free_services is also low, it indicates that the domain has not been configured with adequate services to complete the requests. In such situations, you will have to consider increasing the number of services configured for the domain. |
| Current_services_count |
Indicates the number of services that are actively processing requests to the domain. |
Number |
| Free_services |
Indicates the percentage of services idle in the domain. |
Percent |
| Max_interface_count |
Indicates the number of network interfaces registered with the bulletin board. |
Number |
|
| Current_interfaces_count |
Indicates the number of network interfaces currently in use in the domain. |
Number |
|
| Free_interfaces |
Indicates the percentage of network interfaces idle in the domain. |
Percent |
A high value is desired for this measure.
If the value of this measure is low and the value of the Current_interfaces_count measure is close to that of the Max_interface_count measure, it indicates that the domain has very few interfaces left for handling any additional traffic. Under such circumstances, you may want to assign more network interfaces to the domain. |
| Current_Queue_count |
Indicates the current number of queues in the domain. |
Number |
While a server process waits for a service to complete, other transaction requests wait in a queue until the current service completes. A service may take a fraction of a second to complete or several seconds, depending on the type and complexity of the service. When the service completes, the server process is then available to process the next request in the corresponding queue.
The existence of multiple queues in a domain could be sign of a processing bottleneck in the domain, caused by poor domain configuration. If the value of this measure is high therefore, you may want to check the value of the Free_servers, Free_services, and Free_interfaces, to figure out what resource the domain requires to ensure that there are no hiccups in request processing. |
| Current_groups |
Indicates the number of groups currently available in the domain. |
Number |
|
|