SAPFree calculatorPDF, Excel, Word exportSAP ECC / S/4HANA

SAP RFC Connection Pool Sizing Calculator

External applications calling SAP through RFC or JCo often fail not in the code but at the connection limit. This calculator estimates how many concurrent connections you need and whether the gateway can carry them.

Your numbers

calls/s
0.8 sec

Time the connection is held, including network and the function module runtime.

%
connections

Remaining capacity on the gateway and application servers for this client, from your Basis team.

servers

Your results

Recommended pool size
100
Share of your connection limit used
50%
Average concurrent connections
32
Little's law: arrival rate times time in system.
Peak concurrent connections
80
Connections per application server
34
Spare connections
100
Negative means the pool would exceed the limit.

First-order sizing. Confirm gateway parameters such as gw/max_conn and gw/max_sys with your Basis team, and load test.

Save results:

Recommended pool size vs call duration

Sweeps Average call duration from 0.1 to 5, holding your other inputs fixed.

RFC and gateway capacity review

Optional: a review of your RFC landscape, destinations and limits.

Optional. The tool and every export work without this. No spam.

How to use it

Enter the average number of RFC calls per second from the client application, the average time each call holds a connection, and a peak factor from your busiest period. Add a headroom percentage for retries and bursts. Then enter the number of connections your Basis team can allocate and how many application servers share the load. The result is a pool size for the client and a utilization figure against the SAP side.

The formula

By Little's law, concurrent connections equal arrival rate multiplied by the time each call occupies a connection. Multiplying by the peak factor and headroom gives a pool size. The chart sweeps call duration, which usually matters most: if a function module slows from 0.5 to 2 seconds because of a database problem, the same call rate suddenly needs four times as many connections, which is how a small slowdown becomes a full outage.

Reading the result

If pool size is well under your limit, set it as the maximum pool in the client and keep a lower idle size. If utilization is above 70 to 80 percent, talk to Basis about gateway parameters and logon groups defined in SMLG, or reduce call duration with bulk function modules instead of many small calls. Use SMGW to watch live gateway connections, and SM59 to confirm the destination settings, including load balancing mode.

Common mistakes

Setting an unlimited client pool is the classic error, because a slow backend then consumes every connection and dialog work process. Another is calling one function module per record when a table-based interface exists. A third is forgetting that each connection also uses a dialog work process while a call runs, so limits in SM50 or SM66 matter as well as the gateway.

Frequently Asked Questions

What does a JCo or NCo pool size do?

It caps how many connections the client opens to SAP at the same time. Requests above the cap wait or fail, which protects SAP but can stall your application if sized too low.

Which gateway parameters matter?

Parameters such as gw/max_conn (maximum connections) and gw/max_sys (maximum connected systems) limit the gateway. Ask your Basis team for the current values and what is already used.

Is RFC call duration the function module runtime?

It is the whole time the connection is held: network, authentication on first use, function module runtime and result transfer. Measure it from the client side to be safe.

Should I use tRFC or qRFC instead?

For asynchronous, guaranteed-delivery scenarios, yes. They decouple the sender from the load and are monitored in SM58 and SMQ1 or SMQ2. Synchronous RFC suits request-response needs.

If you are moving from point-to-point RFC calls to a governed integration layer, Netray can help design the interface and the limits around it.