Consultor Eletrônico

Status: Verified

GOAL:

Considerations for managing AppServer resources on UNIX.

FACT(s) (Environment):

UNIX
Progress 9.1x
OpenEdge 10.x

FIX:

6.1.4 Setting the Number of Application Server Processes
For best performance, you must determine the optimal settings for the Server Pool Parameters in the Progress Explorer:

Initial Server Instances to Start (initialSrvrInstance property in ubroker.properties)

Minimum Server Instances (minSrvrInstance property in ubroker.properties)

Maximum Server Instances (maxSrvrInstance property in ubroker.properties)

In general, you must consider the number of clients, the design of your application (including the AppServer operating mode), and the hardware resources that run your AppServer. For more information, see Chapter 3, "Administration."

6.1.5 Choosing a Transaction Model
As discussed in Chapter 2, "Overview of the Progress AppServer," the client application and AppServer run in two separate sessions. Transactions are not propagated between these sessions. However, the AppServer supports two types of transactions:

Normal 4GL transactions¾Where a single transaction begins and ends within the scope of a single remote procedure request from the client. The AppServer starts and manages the transaction within the scope of the remote procedure in exactly the same way a 4GL client starts and manages a transaction within a local client procedure.

Automatic transactions¾Where a single transaction can span multiple remote procedure requests from the client. The AppServer can terminate the transaction at any time from the moment it starts until the end of the connection.

The choice of which type of transaction to use depends entirely upon the nature of your application. By definition, automatic transactions that span more than one remote procedure request tend to be larger than normal 4GL transactions (assuming similar data transfers per request). Also, between multiple client requests with an open automatic transaction, there is more opportunity to make the transaction even larger if UI interactions occur on the client that effectively become part of the same transaction. This, in turn, creates more opportunity for lock conflicts and deadlocks among database clients, including the AppServer session.

For more information on trade-offs and issues for both types of transactions, see the "Transaction and Record Management Considerations" section.

6.1.6 Using Load Balancing
If you install the AppServer Load Balancer for a NameServer installation, you can optimize overall performance based on the machine capacity of each installation. Using this option, the NameServer distributes connection requests among the AppServer installations according to weight factors that you set on each AppServer. For more information on load balancing see Chapter 3, "Administration."


6.2 Secondary Performance Considerations
This section highlights additional specific performance considerations that you should review and understand as you design and implement an application using the Progress AppServer.

6.2.1 Connect and Disconnect Performance Issues
This section discusses performance issues related to connecting to and disconnecting from AppServers.

As with any computer architecture that uses remote-procedure-call technology, the time that it takes to make a connection can be costly. This initial startup time is increased when you use an AppServer Connect procedure.

Using the AppServer Connect Procedure
The AppServer Connect procedure provides a convenient place to perform connection activities. Although these connection activities have value for a variety of reasons, be aware that using these could, to various extents, affect your overall connection performance.

You might want to perform any of the following activities independently of each other, or in combination with any other items:

Authenticate and authorize based on additional parameters you can pass to the Connect procedure (user-id, password, and/or app-server-info).
>For a state-reset or state-aware AppServer, provide security for procedure execution by using the EXPORT( ) method to define the allowed export list for client applications.

NOTE: For a stateless AppServer, you probably want to set the export list in the Startup procedure.

Connect to one or more databases, or to other AppServers on a state-aware or state-reset AppServer.

Initiate application-specific audit trails and/or activity logs.

It might be difficult to predict exact connection speed and the effects of using any, all, or some combination of these options. However, in general, each of these options has some overhead. Although none of these options are required, you might want to consider them as part of your security model. See the "Security Considerations" section for more information.

Performance-related Issue for the CONNECT( ) Method
Connecting to AppServers can be expensive due to process startup and initialization tasks defined in your AppServer Connect procedure. For this reason, you might want to connect to AppServers at client application startup. Also, in most designs, it is advisable that you do not disconnect from AppServers if you intend to use services offered by a particular AppServer more than once prior to ending the client application session.

Performance-related Issues for the DISCONNECT( ) Method
On a state-reset or state-aware AppServer, the DISCONNECT( ) method has no significant performance impact on your client application regardless of whether there is an AppServer Disconnect procedure defined. The AppServer Disconnect procedure is run by the AppServer after the client connection is terminated and DISCONNECT( ) method execution has completed. That is, unlike other procedures executed in an AppServer session, the AppServer Disconnect procedure is run by a state-reset or state-aware AppServer concurrently with processing occurring in the client application.

For a state-reset or state-aware AppServer, you might be able to take advantage of the way the AppServer Disconnect procedure is run to improve overall application performance. When designing your distributed application, consider tasks to be performed by an AppServer that could be performed independently of the connection between the client application and the AppServer. These tasks would typically be ones where the client application does not require any information about the success or failure of the operation. Time-consuming actions are very good candidates for consideration. By moving these tasks to the AppServer Disconnect procedure, these actions can be performed concurrently with other client application processing, improving overall application performance.

On a stateless AppServer, any defined Disconnect procedure runs before the client connection is terminated. Thus, especially for frequent and short-duration connections, you probably want to ensure that the Disconnect procedure does not perform any processing that significantly delays the execution of the DISCONNECT( ) method. This can both impact the client and delay the availability of an Application Server process.


Reference Building Distributed Applications Using the Progress AppServer Version 9 Chapter 6 for additional information..