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.
|