FRENDS PERFORMANCE AND SCALABILITY OVERVIEW
1,300 requests a second, zero errors
A transparent and open deep-dive on the architectural performance and scalability of Frends integration & AI orchestration platform, for CIOs and lead enterprise architects.
Measured results from the standard Frends performance and load test suite on the latest product release (Frends 6.4.0.563 / .NET 10): what each tier sustained, how we tested it, and the numbers behind.
Latest update: August 2026
Bottom line
What the results show
- 01
Most integration platforms interpret each workflow while it runs, so every transaction pays for the engine's own work on top of your own.
- 02
Frends turns each visual workflow into compiled C# / .NET 10 code that the Agent runs directly. The platform adds no more than 2 ms per request, measured directly on the network path.
- 03
Every number here comes from the standard Frends performance and load test suite, which runs against each release.
- 04
The workloads, method and pass criteria are fixed, so results can be compared release over release. This paper reports release 6.4.0.563.
- 05
For the budget holder: platform cost per request does not rise with transaction volume. You pay for the capacity you deploy, not for the messages you send.
≤2 ms
Added by the platform per request
The same on both tiers, at every load level we tested. Measured directly, and small enough to disappear into normal network noise.
1,300 RPS
Enterprise floor, tested and passed
Two agents running active-active, zero errors. Add an agent, get more capacity.
>2x
Double the throughput on double the compute
Multi-step throughput at the two-agent Enterprise floor compared with a single Business agent. One agent alone tops out before load can be spread across a cluster.
~104 ms
A realistic multi-step workflow, start to finish
Median time for a workflow that makes two real calls to external systems (Enterprise). The Business figure needs a dedicated run before we publish it.
0
Errors above the floor
Requests queued above the Enterprise floor with elevated response times; zero errors observed.
Section one
Why Frends is fast
Workflows are compiled, not interpreted at runtime — and the control plane is kept separate from where your data is processed.
Most integration platforms interpret workflows at runtime. A definition — BPMN, XML, a proprietary schema — is parsed, resolved and executed step by step, every time a request arrives. That parsing is work the engine does on top of the work the business asked for, and it recurs per transaction.
Frends removes it. The visual workflow designer generates standard C# source, the .NET 10 compiler turns it into an assembly, and the Agent executes that assembly directly. There is no definition left to interpret at runtime.
Platform execution overhead is the cost the platform adds to a request, separate from the work the request itself performs. On Frends it is bounded at no more than 2 ms, constant across both tiers and every load level measured.
Runtime
Assembly executes directly
The Agent executes the compiled assembly: no BPMN parser, no XML resolution layer, no scripting interpreter. Platform execution overhead is no more than 2 ms per request.
Solid marks happen per request. Outlined marks happen once, before deployment. Select a mark to read it.
Two planes, scaled separately
The control plane is cloud-hosted and handles design, version control, deployment, monitoring and alerting. Its cost is fixed regardless of agent count or throughput. The execution plane is Agents running inside the customer’s own infrastructure, co-located with the systems they serve.
Because the two scale independently, adding execution capacity does not add control-plane cost, and integration data stays inside the network perimeter unless a workflow explicitly routes it elsewhere.
Execution plane
Frends Agents, lightweight processes running inside the customer's own infrastructure: on-premises, in a private cloud tenant, or co-located with the data stores they serve.
Control plane
Cloud-hosted. Manages workflow design, version control, deployment, monitoring and alerting. Its cost is fixed regardless of agent count or throughput.
Disconnected mode
Agents keep executing during control plane connectivity loss; logs buffer locally and synchronise on reconnect.
Section two
How we tested
Three workloads, fixed pass criteria, and a latency calculation any architect can check for themselves.
The figures in this paper come from the standard Frends performance and load test suite, which runs against every version release. Fixed workloads, fixed methodology and fixed acceptance criteria make results comparable release over release. What follows is the suite’s result for the current release, 6.4.0.563.
Direct API routing
A request arrives, Frends logs it and returns a response. No downstream system calls.
Isolates the Frends platform overhead and establishes the sub-2 ms execution baseline independent of any external system.
Multi-step API orchestration
A request arrives; Frends makes two downstream requests to external systems in sequence — one to fetch data, one to deliver it — transforms the payload between steps, logs the execution and returns a response. The Azure-hosted agent calls GCP-hosted external systems, so each call carries that system's response time and network path.
A common enterprise pattern: receive, transform and route data across multiple systems in one workflow.
Large-file batch processing
Frends generates and processes a multi-gigabyte file — CSV generation and XML transformation — per execution cycle, run both sequentially and concurrently.
Tests memory stability and throughput under the sustained large allocations typical of ETL pipelines and bulk data exchange.
Test discipline
- Fixed cool-down periods between ceiling steps, so no reading carries load from the step before it.
- Config-driven test orchestration. The test sequence is defined in configuration, not run by hand.
- Isolated multi-step sessions, so no preceding test can contaminate the reading.
- Zero-error acceptance criterion. A throughput ceiling counts only at zero errors.
- 30-second sustained analysis windows for every throughput figure.
What is measured
Throughput
Peak sustained requests per second at zero errors; highest rate before error onset.
Latency
Median (p50) and 95th-percentile (p95) response time at each load level.
Memory stability
Behaviour under sustained large-file workloads across 100+ consecutive executions.
Failure mode
How each tier behaves when load exceeds its ceiling.
One caveat worth stating plainly: throughput figures are measured over 30-second sustained windows. That measures burst capacity, not endurance. Separate 24- to 48-hour endurance results are not part of this suite.
Section three
How much each tier handles
What Business and Enterprise sustained at zero errors on this release, and the three things that decide which one you need.
≤0 ms
platform execution overhead per request, constant across both tiers and all load levels
0 RPS
validated Enterprise floor on a two-agent active-active cluster, at zero errors
| Tier | Architecture | Direct routing | Multi-step | Large file |
|---|---|---|---|---|
| Business | Single-agent | 700 RPS | 500 RPS | Sequential, stable |
| Enterprise | Active-active HA (2-agent floor) | 1,300 RPS+ | 1,100 RPS+ | Concurrent, stable |
Table 1 — Peak sustained requests per second at zero errors, release 6.4.0.563.
Three things decide which tier you need
Concurrency & scaling
Business
Single-agent runtime. Designed for predictable, steady-state workloads up to 700 RPS on direct routing and 500 RPS on multi-step orchestration.
Enterprise
Active-active multi-agent clustering for scenarios that require high availability. Validated two-agent floor: 1,300 RPS routing and 1,100 RPS multi-step at zero errors, designed to scale horizontally by adding agents.
Fault tolerance under stress
Business
Single-agent architecture running at full efficiency to its ceiling. As with any high-efficiency single-node system, response times rise before errors appear. Standard posture: response-time percentiles alongside error rates.
Enterprise
Distributed active-active architecture with no single agent as a point of failure. Tested above the two-agent floor: zero errors observed, with elevated response times only.
Data streaming & payloads
Business
Handles standard API payloads and structured batch runs. Sequential large-file processing, multi-gigabyte files per execution, ran stably with no memory growth over sustained runs.
Enterprise
Concurrent large-file processing. The distributed cluster splits large workloads across nodes, validated under concurrent multi-gigabyte executions. Node distribution and infrastructure I/O configuration are required conditions.
Table 2 — Configurations beyond two agents were not separately benchmarked; horizontal scaling beyond that point is an architectural property, not a measured result.
Section four
Speed, load and resource use
Three findings: platform overhead stays flat, doubling the compute more than doubles multi-step throughput, and nothing failed above the floor.
Three findings come out of the test matrix. The first is that platform overhead is fixed: no more than 2 ms per request, unchanged at 50 RPS and at 1,300 RPS. End-to-end figures measured from an external test client are larger because they include the public internet round-trip, measured directly at 36,1–36,7 ms.
| Workload | Platform execution overhead | Notes |
|---|---|---|
| Direct API routing | ≤2 ms | Bounded by direct measurement; below the noise floor of a public-network measurement. |
| Multi-step API orchestration | ≤2 ms + downstream call latency | Each external call is additive, proportional to that system's own response time. |
| Direct routing, observed end-to-end† | 35.3–35.7 ms p50 / 37.0–38.7 ms p95 | Client-to-agent round-trip measured directly; no residual estimate. |
| Multi-step orchestration, measured end-to-end† | ~104 ms p50 / up to 401.6 ms p95 | Enterprise; realistic two-call scenario with two real outbound downstream calls. Business-tier figure pending a dedicated isolation run; p95 range includes the Enterprise stepped-test tail. |
Table 3 — † Observed figures from the external test client include the internet round-trip measured directly in the test setup. Co-located production agents remove that component.
Frends platform cost, isolated
≤2 ms
Bounded by direct network-path measurement; constant across tiers and load levels.
Direct routing, observed end-to-end
35.3–35.7 ms
Includes the public internet round-trip of 36.1–36.7 ms measured directly.
Multi-step, end-to-end (Enterprise, two real calls)
~104 ms
Two real outbound downstream calls, payload transformation, logging and dispatch.
Behaviour above the ceiling
The second finding is how each tier fails. Both saturate the same way — response times rise before errors appear — which makes p95 alerting a more useful early signal than error-rate dashboards. Above the Enterprise two-agent floor, requests queued with elevated response times and zero errors were observed.
Business
- At the ceiling
- Response times elevate; agent at full capacity.
- Above the ceiling
- Requests queue; response time rises.
- Recovery
- Response-time alerting gives lead time to scale.
Enterprise
- At the ceiling
- Response times elevate; zero errors observed.
- Above the ceiling
- Requests queue and response times rise across load-balanced active-active agents; errors stay at zero. No single agent as a point of failure.
- Recovery
- Add agents as a planned capacity step.
What scaling looks like
The Enterprise two-agent floor is a starting point
1,300 RPS routing and 1,100 RPS multi-step at zero errors; capacity grows by adding agents. Beyond two nodes was not separately benchmarked.
Platform overhead is a measured constant
No more than 2 ms per request at both tiers; tier selection raises aggregate throughput, not per-request time.
Business monitoring is response-time-first
p95 percentile alerting detects saturation before error-rate dashboards can.
Concurrent large-file processing is an Enterprise architectural property
Business handles the same workloads sequentially with full stability; the suite re-tests this boundary at every release.
Section five
What this means for cost
What the data supports about spend, what it does not, and which tier fits which scenario.
The commercial consequence of fixed platform overhead is that cost per request stays decoupled from transaction volume. Infrastructure spend follows deployed capacity, not message counts, so a volume forecast becomes a capacity question rather than a licensing one.
What the data does not support is a cost comparison against any named competitor. Nothing here was measured against another vendor’s platform, and no pricing model other than the Frends one is represented.
| Tier | Direct routing | Multi-step | Large file | Fault tolerance |
|---|---|---|---|---|
| Business | 700 RPS | 500 RPS | Sequential, stable | Response-time monitoring standard |
| Enterprise | 1,300 RPS+ | 1,100 RPS+ | Concurrent, stable | Zero-error under overload |
Table 5 — Throughput capability by commercial tier, for capacity planning.
Which tier fits which scenario
- Steady-state API and orchestration workloads within single-agent capacity (up to 700 RPS routing, 500 RPS multi-step)
- Business
- Sequential large-file and batch processing
- Business
- Active-active high availability; zero-error behaviour under unpredictable peak load
- Enterprise
- Concurrent large-file distribution across cluster nodes
- Enterprise
- Volume targets above the two-agent floor (1,300 / 1,100 RPS)
- Enterprise, scaled horizontally
Table 6 — Scenario-to-tier mapping.
Method statement
How to read these numbers
All figures come from the standard Frends performance and load test suite, run against release 6.4.0.563. Throughput ceilings are peak sustained requests per second at zero errors, measured over 30-second analysis windows with fixed cool-down periods between steps.
Test agents ran on Azure and called external systems hosted on GCP, so multi-step figures carry both the downstream system’s response time and a real network path. Client-to-agent round-trip time was measured directly at 36,1–36,7 ms and is included in every observed end-to-end figure; co-located production agents remove it.
Three limits are stated rather than smoothed over: the Business-tier multi-step latency figure is pending a dedicated isolation run; configurations beyond two agents were not benchmarked, so horizontal scaling above the two-agent floor is architecture rather than measurement; and 30-second windows measure burst capacity, not endurance.
Take the next step
See how your current platform compares
Send us your transaction volumes, workload mix and what you pay today. We will map them against the throughput and tier capacity measured in this paper.