Page 1 of 1

A server under load behaves differently

Posted: Fri Oct 30, 2026 11:45 am
by Fairman
A server under load behaves differently

When volatility spikes, thousands of traders send orders at the same moment. The broker's server queues them. The queue creates delay, and the delay grows with the load.

Retail traders feel it as slow fills, rejected orders, or temporary freezes. Order processing at the broker is typically first-in, first-out, but the exact rules differ.

The delay during these peaks can be many times normal. An order that takes 80 milliseconds on a quiet day might take two seconds during NFP.

A scalper using tight stops during these events faces larger slippage than the spread and price alone suggest, because the order sits in a queue while the market moves.

Anything that reduces the number of requests helps. Pre-positioned orders do not need to be sent at the critical moment. Fewer modifications and cancellations avoid adding to the load.

What did execution time look like at the last major release compared with a normal day?

Re: A server under load behaves differently

Posted: Wed Nov 04, 2026 12:35 pm
by Fairman
Broker servers handle orders from many clients at once, and at busy moments, such as major news releases or the weekly open, the load can increase sharply. Under heavy load, execution can slow down, requotes can become more frequent, and some orders may be rejected with errors such as trade context busy or server busy. These problems are usually temporary, but they happen at exactly the times when fast execution matters most. A strategy that performs well in normal conditions may struggle during these periods, and backtests rarely capture the effect, since they assume orders are processed instantly regardless of market conditions.

Re: A server under load behaves differently

Posted: Wed Nov 04, 2026 5:19 pm
by Amanhasnoname
I noticed the queue effect most clearly during an NFP release a while ago. Normally my fills took about a tenth of a second, but during that minute my market orders took close to three seconds, and one of them was rejected outright with a busy message. I was using a four pip stop, which in that situation meant very little.

Since then I changed three things. I place pending orders ahead of time, even if it means a slightly worse entry, because they do not need to travel through the queue at the worst moment. I stopped moving stops during releases, and I cut the number of modifications I send in general.

To compare it with a normal day, I logged the time between order send and fill in a spreadsheet for a month. The release days were five to ten times slower, and that was enough to change how I size around news. On those days I simply trade smaller or sit out the first minute.