Incoplax platform · April 2026
We ran the Incoplax contact center on a seven-server cluster for three days without a break: 4,000 agents, 10 inbound and 125 outbound calls every second, and 2,500 conversations at once.
The test passed. Every agent operation met its response-time target, recordings stayed clean, and the servers never went above 50% CPU or 45% memory, enough headroom to double the load on the same hardware.
The test bench was a full Incoplax cluster surrounded by emulators: thousands of simulated customers on the phone lines and thousands of simulated agents with desk phones and web applications.
| Inbound | 1,000 |
|---|---|
| Outbound | 1,000 |
| Blended | 1,000 |
| Second line | 1,000 |
| Test | 10 |
| Total | 4,010 |
| Inbound calls | 10 per second |
|---|---|
| Outbound calls (predictive campaign) | 125 per second |
| Call list | 375,000 contacts |
| Contact rate of the list | under 20% |
| Wrap-up after each call | 10 seconds |
| Agent apps driven by emulators | 200, 50 per group |
|---|---|
| Status change | every 30 seconds |
| Agents in “Not ready” | 10% |
| Test log-on / log-off | every 60 seconds |
Seven servers, each an Intel Core i7-13700 with 16 GB RAM and a 290 GB SSD. PostgreSQL ran outside the cluster as two instances: one for the call list and settings, one for archives (calls, conversations, queue and campaign records, statistics). No external storage: recordings stayed on a local disk and were checked and cleared several times a day.
Three servers of the same configuration ran the SIP emulators for carriers and agent devices. The database servers were added to it so that all performance data could be watched in one place.
The cluster was laid out by job: SIP and voice services on two servers, media on three, the product layer on one and data on one. What each role does is explained on the architecture page.
Also: mdc, mic, ic, rpci, rpco, rsv
Node.js product services: contact center, ACD, outbound, statistics
Also: usr, svc, fs, st, logstore, ap, sel, vmail, email, im
The test followed a written methodology with fixed response-time targets for every agent operation. A short rehearsal checked the bench; the main run then held full load for three days.
One pass of the outbound campaign through all 375,000 contacts plus 30,000 inbound calls. Dashboards and performance monitors were captured, recordings spot-checked, counters and metrics analysed.
Result: no deviations; the bench was ready for the main run.
Continuous load of 10 inbound and 125 outbound calls per second. The outbound campaign restarted every 30 minutes so that it never idled while waiting for scheduled callbacks, and the recordings folder was cleared periodically.
Result: test passed; two database bottlenecks were fixed without stopping the load.
Each figure is measured on the agent side: from the moment the agent application sends a command to the moment it receives the resulting event. Every operation met the methodology's targets.
| Operation | Target | Average, as a share of the 90% target | Max | Within target | Measurements |
|---|---|---|---|---|---|
| Agent log-onagent.logonTarget 90% ≤ 3 s, rest ≤ 6 s | 90% ≤ 3 s, rest ≤ 6 s | 2,269 ms | 3,033 ms | 98.5% | 15,058 |
| Agent log-offagent.logoffTarget 90% ≤ 3 s, rest ≤ 6 s | 90% ≤ 3 s, rest ≤ 6 s | 4.8 ms | 217 ms | 100% | 15,054 |
| Answer a callcall.answerTarget 90% ≤ 1 s, rest ≤ 2 s | 90% ≤ 1 s, rest ≤ 2 s | 7.3 ms | 178 ms | 100% | 91,195 |
| Hang upcall.dropTarget 90% ≤ 1 s, rest ≤ 2 s | 90% ≤ 1 s, rest ≤ 2 s | 1.4 ms | 45 ms | 100% | 89,453 |
| Blind transfercall.transfer.blindTarget 90% ≤ 2 s, rest ≤ 3 s | 90% ≤ 2 s, rest ≤ 3 s | 41 ms | 509 ms | 100% | 111,131 |
| Outgoing callcall.makeTarget 90% ≤ 2 s, rest ≤ 3 s | 90% ≤ 2 s, rest ≤ 3 s | 77 ms | 913 ms | 100% | 113,259 |
| Start consultative transfercall.transfer.startTarget 90% ≤ 2 s, rest ≤ 3 s | 90% ≤ 2 s, rest ≤ 3 s | 78 ms | 901 ms | 100% | 91,699 |
| Complete consultative transfercall.transfer.finishTarget 90% ≤ 1 s, rest ≤ 2 s | 90% ≤ 1 s, rest ≤ 2 s | 170 ms | 1,767 ms | 98.3% | 90,205 |
| Operation | Average | Max | Result | Measurements |
|---|---|---|---|---|
| Assemble a conference | 1,030 ms | 1,137 ms | 100% within 2 s | 45,293 |
| Place a call in a queue | 17 ms | 757 ms | 100% within 1 s | 198,879 |
| Route a queued call to a free agent | 0.3 ms | 8 ms | 100% within 1 s | 125,654 |
Sampled recordings of every agent group were clean on both channels: no dropouts, crackle or other distortion.
The methodology sets the ceiling at 70% CPU and 80% memory. Throughout the test the cluster stayed well below both, with even curves and no spikes.
against a 70% ceiling
against an 80% ceiling
about 250 Mbit/s between the product layer and the data model
mostly recordings on the media and data servers, thanks to the external databases
A long run finds what a short one cannot. Both issues it surfaced sat in the external PostgreSQL databases, not in the platform, and both were fixed on a live system without lowering the load.
The predictive campaign updates the call list twice per call: 250 updates a second. After six hours the database queue overflowed and the outbound service restarted once. The call-list class was switched to work through the platform's message broker, applied on the fly. The warnings stopped and there were no further restarts.
After a day the call archive held more than 10 million rows, and several parallel aggregate queries from the full supervisor dashboard overloaded it. A lightweight dashboard (current state and last hour) was added, and a patch that queues heavy queries was built and installed during the test. For archives of this size the recommended setup is Kafka with ClickHouse.
Test passed
With CPU at 25–50% and memory at 20–45%, the same seven servers could take twice the load after a minor reshuffle of microservices and stay within 70% CPU and 80% memory. What drives resource use is the number of simultaneous conversations, IVR sessions and calls per second, and the microservice architecture scales all three horizontally.
The run also proved in practice that individual components can be patched under heavy load without interrupting calls in progress.