Building Distributed
Applications
Using the Progress AppServer
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).
NOTE: For a stateless AppServer, you probably want to set the export list in the Startup procedure.- 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.
- 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.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |