Try OpenEdge Now
skip to main content
Application Migration and Development Guide
Application Development with PAS for OpenEdge : Design and Implementation Considerations : Primary performance considerations : Choosing an application model : Application characteristics to consider
Application characteristics to consider
To understand the trade-offs between these application models, you must first determine the goals of your application. In general, each application model offers different trade-offs among three general characteristics:
*Design complexity
*Resource consumption
*Performance (request throughput and response time)
The best application model for your application depends on a number of factors, including:
*The complexity of the application
*The amount of context that needs to be maintained between requests
*The current and future performance goals for the application
*The computer resources available for the PAS for OpenEdge machine (or machines)
In some cases, it might be significantly more complex to program your PAS for OE application with one application model rather than another. In many cases there might be more than one application model and design strategy that is appropriate. The purpose of this section is to explain some of the trade-offs associated with each application model so you can determine the most appropriate application model and design strategy to use for your situation.
The following table lists each application model, comparing it in terms of the three general characteristics with performance divided between throughput and response time. These comparisons apply, for each application model, in a network where available PAS for OpenEdge resources are the same.
Table 17. Characteristic application model trade-offs
Application Model
Design complexity
Resource consumption
Request throughput (requests/second)
Average response time (seconds/request)
Depending on the connection binding, shared client and PAS for OE session context can be established and managed for each request using the Activate procedure, then reset using the Deactivate procedure. When an unbound connection state is used, tends to be extremely complex if context is complex.
Many clients per PAS for OpenEdge session (unbound); One client per PAS for OpenEdge session (bound)
Maximum throughput under heavy client load where context is maintained, computing resources are limited, and requests are short. Assumes none or minimal use of bound connections. Bound connections of long duration can significantly limit throughput. Even when connections are unbound, large complex connection context can also limit throughput.
With a bound connection, a large shared context, and the same computing resources, performs requests faster for the bound client than for clients making requests over an unbound connection.
Easiest to program where little or no context is maintained. Any shared client and PAS for OpenEdge context must be established and managed for each request using the Activate procedure. You can reset the context using the Deactivate procedure. This application model tends to be the most complex if context is complex. Because no Connect procedure executes for the client connection, requires a separate login verification in the Activate procedure to establish or retrieve the current login session for each client request.
Varies directly with client load, but tends to support many more clients per PAS for OpenEdge instance and session
Highest throughput under heavy client load, especially where multiple PAS for instances are available to support a single business application using a DNS load balancing service. Offers the greatest scalability, especially where no or minimal shared context is maintained between clients and sessions.
Has best possible response time for heavy client load with none or minimal shared context, and using the same computing resources as a session-managed connection. Performs less well for a given client than using a bound session-managed connection, especially given significant shared context.