The daily edition.

SEP Count Is a Workload-Shape Decision, Not a Generic Capacity Knob

Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX, Enterprise Server region configuration and performance.

Service Execution Processes (SEPs) form the region’s application-execution pool. The SEP Count field on the region’s General Properties page specifies how many SEPs start during server initialization. This is a startup option: changing the value while the region is running does not take effect until the next server start. The same page cautions that changing properties of a registered region can cause application connection errors and data loss. See General Properties.

The useful sizing insight is that the process count should follow the work’s blocking behavior, not simply anticipated request volume.

• CPU-bound services: Services that perform little or no I/O are constrained by processor use. Fewer SEPs usually work better because switching the processor among running tasks adds overhead. CPU-bound Services therefore ties SEP sizing to CPU contention rather than treating a larger pool as automatically faster.
• I/O-bound services: Services performing substantial I/O often remain dormant while awaiting responses. More SEPs may be needed so other work can proceed during those waits. However, the documentation also notes that processing I/O requests can itself place considerable demand on the CPU, so I/O volume does not remove processor constraints. See I/O-bound Services.
• Long-running stateful requests: When the same client repeatedly invokes a service and requires data to persist between invocations, that service can remain associated with the client for an extended period. More SEPs are needed even when the service itself is CPU-bound. Enterprise Server automatically starts a new SEP when it detects a stateful request, but dynamic SEP growth consumes machine resources and can affect region performance. Rocket recommends minimizing these requests unless the application design requires stateful interaction. See Long-running Client Requests.

This creates two separate operational considerations. The configured SEP Count establishes the pool available when the region starts. Runtime workload behavior then determines whether that pool causes unnecessary CPU switching, covers periods in which processes wait on I/O, or expands dynamically because client state must be retained. A count suitable for stateless CPU-bound calls can therefore be unsuitable for I/O-heavy or long-lived stateful traffic.

Changing SEP Count is also not an immediate live-tuning action. Because it belongs to the startup options, the new configured count is applied only at the next region start; any change must be treated as a region configuration operation rather than an instantaneous concurrency adjustment.

Takeaway: Size the startup SEP pool from the workload profile—conservative for CPU-bound work, larger where I/O waits occupy processes, and with explicit allowance for stateful requests that can cause automatic SEP growth.