Plataformas · Software · Provedores · Mercados
Can this platform handle launch-day traffic? The useful answer is one backed by a measured workload, a known operating limit and evidence that the service recovers when a component fails. A login test or a high request count alone cannot provide that evidence.
Load testing is a controlled attempt to make a production-like system process the activity it is expected to receive, then observe where it slows, queues or fails. For a broker or prop firm, that means following orders through the actual chain: client connection, authentication, risk checks, order management, bridge or gateway, and any execution simulator or venue connection. The market-data path matters too. A platform can accept orders while delayed quotes, stale prices or disconnected sessions make it unusable.
Start by writing down the launch decision the test must support. It might be whether the service can sustain a stated rate of order submissions for an hour, or whether it can return to normal after losing a gateway.
Decide which limits are acceptable before running the test. Engineers comparing platform components and suppliers can use Trading Technology's broker infrastructure coverage as context, but capacity still has to be measured against the firm's own workload and configuration.
Define the workload before choosing a tool
A virtual user is not a workload model. One user might log in, place a market order and leave. Another can maintain several streaming subscriptions, modify orders repeatedly and reconnect after a network interruption. Model the behaviours that affect the system, not just the number of simulated accounts.
Use product and operations data where it exists: expected funded accounts, concurrent sessions, historical order bursts, instrument mix, session times and market-data subscriptions. For a new product, make assumptions explicit. Estimate active users from launch registrations, conversion assumptions and the share likely to be online at the same time.
Then model quiet periods and concentrated bursts separately. A news event or market open can produce a short peak several times the average rate.
Include the transactions that consume different resources:
- Logins, token refreshes and session reconnects, which can load identity services and connection pools.
- New, replace and cancel requests, with realistic proportions of market and pending orders.
- Risk checks for margin, exposure, symbol limits and account state, including rejected orders.
- Market-data subscriptions and outbound quote updates, grouped by instrument popularity.
- Position, order-history and balance queries, which often hit databases or caches differently from order entry.
- Disconnects, retries and duplicate submissions, so idempotency and recovery paths are exercised.
Separate the rate of requests from the number of connected sessions. Ten thousand idle connections can test socket handling but say little about order throughput.
Conversely, a few hundred highly active sessions can saturate a risk service. Specify think time between user actions, payload sizes, protocol mix and the distribution of activity across accounts. A closed-loop generator waits for a response before sending the next action, so it can hide overload by reducing its own rate. An open-loop generator sends at a fixed rate and reveals queue growth, but needs controls to avoid overwhelming the test environment without recording the cause.
Build a representative test, not a synthetic victory
Use production-like software versions, configuration, message formats and network paths. Match the key limits: thread and connection pools, database indexes, cache sizes, rate limits and file descriptors.
Where the production environment has a cloud load balancer, firewall inspection or a FIX gateway, include it or document the difference. A test on an oversized staging cluster will produce reassuring numbers that do not transfer to launch.
Do not route uncontrolled traffic to a live liquidity provider, exchange or payment service. Use a simulator or a contracted test endpoint, with explicit limits on message rates and order values. Scrub personal data, but preserve the fields and distributions that affect query plans, risk rules and routing.
Test accounts should cover different use, margin, instrument and permission settings. A single clean account is not representative.
The figures below are typical planning ranges for a retail broker or prop platform test, not universal service levels or audited results. Actual figures vary with architecture, instrument count, protocol and market-data design. Use them to check whether a test plan is in a plausible order of magnitude, then set targets from the firm's own forecast and risk tolerance.
| Measure | Typical planning range | What the test should reveal |
|---|---|---|
| Concurrent client sessions | 1,000 to 20,000 | Connection stability, authentication load and reconnect behaviour |
| Order requests at peak | 50 to 500 per second | Acceptance rate, risk-service capacity and queue growth |
| Market-data updates fanned out | 10,000 to 500,000 per second | Outbound bandwidth, subscription handling and client lag |
| Internal order acknowledgement, p95 | 50 to 200 milliseconds | Time through the firm-controlled path, excluding external venue delay |
| Sustained critical-service CPU | 60% to 75% | Whether headroom remains for bursts, retries and failover |
These are broad ranges, not launch pass marks. For example, a market-data service sending fewer messages may still be constrained by a small set of heavily subscribed symbols. A low average CPU reading can also conceal one saturated worker or a database connection pool at its limit. Capture per-service and per-instance measurements, not just a platform-wide average.
Run the test in controlled stages
Agree a test window, an owner for each system and a stop condition before generating traffic. Notify network, database, security and support teams.
Keep an out-of-band channel open, and ensure the test can be stopped without depending on the service under test. The following sequence gives operators evidence in manageable steps.
- Validate the harness. Run a small workload and compare generator-side counts with server-side logs. Check clocks, request identifiers, response parsing and error classification. If the generator is CPU-bound, the platform result is not valid.
- Establish a baseline. Record latency, throughput, error rates, queue depth, CPU, memory, network use, database waits and cache hit rates under light activity. Include the same dashboards and logs planned for launch operations.
- Ramp in stages. Increase sessions and request rates gradually, for example in steps of 20% to 30%, holding each level long enough for queues and caches to settle. Compare delivered load with completed transactions; a generator's send rate is not proof of completed work.
- Test the expected peak and a safety margin. A common planning approach is to test around 1.5 to 2 times the forecast peak, then check whether the service degrades predictably. The margin is not a substitute for a forecast, and it may be too high or too low for a particular product.
- Apply a burst. Increase activity sharply over seconds, rather than only using a smooth ramp. This exposes autoscaling delays, connection storms, queue limits and throttling behaviour. Include reconnects after a simulated network interruption.
- Run a soak test. Hold a representative load for several hours, often 4 to 12 in a pre-launch exercise. Watch for memory growth, connection leaks, log volume, storage pressure and slow database accumulation.
- Exercise failure and recovery. Remove a worker, gateway or database replica using an approved method. Check what clients see, whether orders are duplicated or lost, how long recovery takes, and whether queued work drains without causing a second overload.
Do not change several capacity settings at once. If a test fails, preserve the workload and change one factor, such as worker count or connection-pool size. Otherwise, a better result will not show which change mattered. Save test scripts, configuration, build identifiers and dashboards alongside the results so the run can be repeated after a fix.
Set a launch gate from observed behaviour
Throughput is only one part of the decision. Review latency distributions, not only averages.
A p95 or p99 response time shows what slower requests experience; a healthy mean can coexist with a long tail caused by lock contention or garbage collection. Track each important boundary with timestamps, and distinguish internal order acknowledgement from execution confirmation. A slow external venue should not be mislabelled as a slow platform, and a fast acknowledgement must not be presented as proof of a completed trade.
Operators should correlate user-visible symptoms with service-level signals. A practical dashboard for a launch test usually includes:
- Requests sent, accepted, rejected, timed out and retried, by operation and service.
- P50, p95 and p99 latency for login, order acceptance, cancel and market-data delivery.
- Queue depth and oldest-message age at each asynchronous boundary.
- CPU, memory, garbage collection, network throughput, database waits and connection-pool use.
- Market-data lag, disconnected sessions, stale-price events and resubscription rates.
- Recovery time and the number of orders reconciled after each injected failure.
Agree failure thresholds before the run. They might include a maximum p99 order-acceptance time, a tolerated error rate, a queue that must drain within a stated interval, and no unexplained loss or duplication of orders. These values are product-specific. A platform may be technically available but still fail the operational test if support cannot identify the affected accounts or reconcile order state.
Keep a written record of the tested peak, the point where latency began to rise, the first saturated component and the recovery behaviour. If capacity tops out before the forecast, reduce scope, add capacity or change the launch plan, then repeat the same workload. Do not treat a green dashboard at one load level as proof of resilience. The launch gate should state the tested limit, the assumptions behind it, known constraints and the owner who accepts any remaining risk.
Trading systems often find their least tested minute during the busiest one.
Perguntas frequentes
How long should a trading platform load test run?
A useful exercise includes short ramp and burst tests, plus a soak test often lasting 4 to 12 hours. Run longer if the product has known overnight jobs, daily resets or slow resource leaks that will not appear in a shorter window.
What should be measured during broker platform load testing?
Measure completed throughput, p50, p95 and p99 latency, errors, retries and queue depth across the order and market-data paths. Add CPU, memory, database waits, connection pools, market-data lag and recovery time after a controlled failure.
Can load testing be done against a live trading venue?
Only with explicit permission, agreed rate limits and a controlled test plan. Most pre-launch testing should use a simulator or approved test endpoint, because uncontrolled orders can create financial, operational and regulatory risk.
