Try OpenEdge Now
skip to main content
Developing AppServer Applications
Design and Implementation Considerations : Primary performance considerations : Choosing an AppServer operating mode : Application characteristics to consider
 
Application characteristics to consider
To understand the trade-offs between these operating modes, you must first determine the goals of your application. In general, each operating mode offers different trade-offs among three general characteristics:
*Design complexity
*Resource consumption
*Performance (request throughput and response time)
The best operating mode 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 AppServer machine
In some cases, it might be significantly more complex to program your AppServer application with one operating mode rather than another. In many cases there might be more than one operating mode and design strategy that is appropriate. The purpose of this section is to explain some of the trade-offs associated with each operating mode so you can determine the most appropriate operating mode and design strategy to use for your situation.
The following table lists each operating mode, comparing it in terms of the three general characteristics with performance divided between throughput and response time. These comparisons apply, for each operating mode, in a network where available AppServer resources are the same.
Table 8. Characteristic operating modetrade-offs
Operating mode
Design complexity
Resource consumption
Request throughput (requests/second)
Average response time (seconds/request)
State-reset
Easiest to program where context is maintained. AppServer session context automatically reset at the end of each connection.
One client per AppServer agent
Might be limited with limited computing resources because the number of clients that can be concurrently serviced is limited to the number of AppServer agents.
Fast response time where computing resources are not limited. The client communicates directly with a dedicated AppServer agent.
State-aware
Appropriate AppServer session context must be reset manually, typically in the Disconnect procedure. Tends to be complex if context is complex.
One client per AppServer agent
Might perform better than state-reset where reusable context can be established in the Startup procedure and reused for each connection. Assumes minimal context reset after each connection.
Might perform better than state-reset where reusable context can be established in the Startup procedure and then reused for each connection. Assumes minimal context reset after each connection.
Stateless
Appropriate AppServer session context must be established and managed for each request using the Activate procedure, then reset using the Deactivate procedure. Tends to be extremely complex if context is complex.
Many clients per AppServer agent (unbound); One client per AppServer agent (bound)
Maximum throughput under heavy client load where context is maintained, computing resources are limited, and requests are short. Assumes 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 minimal client load and unlimited computing resources, performs less well than state-aware or state-reset for small client load because two IPC messages are needed per request. Long bound connections can severely limit response time. Even with unbound connections, large complex connection context can limit response time.
State-free
Easiest to program where little or no context is maintained. The AppServer context can be established and managed for each request using the Activate procedure. You can reset the context using the Deactivate procedure. This mode tends to be extremely complex if context is complex.
Varies directly with client load, but many clients per AppServer broker and agent
Maximum throughput under heavy client load, especially where multiple AppServers are available to support a single application service. Offers the greatest scalability.
Has best possible response time for heavy client load with limited computing resources. Performs less well than state- aware or state-reset for a small client load because two IPC messages are needed per request. Offers the greatest scalability.