Tracking 5,000 Live Drivers: A Reproducible Laravel Reverb Load-Test Plan

Five thousand simulated drivers. One defined location cadence. The same payload, route mix, cloud region, and observability stack on both sides.

That is the minimum shape of a useful comparison between an existing Node.js socket service and Laravel Reverb. Without a controlled workload, claims about memory and latency are framework marketing rather than engineering evidence.

This article documents the harness App Clone Labs would use before moving a logistics real-time layer. It does not claim that Reverb is universally faster than Node.js. It shows how to produce evidence about two implementations under one repeatable driver-telemetry workload.

The workload to test

A driver-tracking benchmark is meaningless if “5,000 users” means 5,000 idle browser tabs. The useful unit is active connections multiplied by update frequency and fan-out.

Use this test profile:

• Concurrent WebSocket connections: 5,000
• GPS update intervals: 1, 5, and 15 seconds
• Payload: a versioned coordinate event containing driver, trip, timestamp, accuracy, bearing, and speed fields
• Channels: authenticated driver, order, fleet, and operations scopes
• Dispatch viewers: measured separately from driver connections
• Fan-out: one, five, and 20 subscribers per location event
• Duration: a 10-minute warm-up followed by a 30-minute measured run
• Application hosts: identical CPU, RAM, operating system, and region
• Redis: identical topology and placement
• TLS termination: the same NGINX proxy configuration
• Load generation: source-region latency reported separately from server processing

Measure connection success, disconnects, messages per second, p50/p95/p99 end-to-end delivery latency, process RSS, CPU, Redis throughput, event-loop lag, and reconnect recovery.

Laravel documents that Reverb can expose connection and message counts through Laravel Pulse. It also supports horizontal scaling through Redis pub/sub, with multiple Reverb servers placed behind a load balancer. Those capabilities can make measurement and operational ownership simpler inside a Laravel application. They do not replace application-level latency traces. (Laravel Reverb documentation)

The comparison was not “PHP versus JavaScript”

That framing is too shallow.

The Node.js service and Reverb were both long-running WebSocket processes. The material differences were elsewhere:

1. How authentication and channel authorization crossed the main application boundary.
2. How location events were serialized and broadcast.
3. How Redis was used for cross-process fan-out.
4. How stale connections were pruned.
5. How deploys restarted workers without turning every driver offline at once.
6. How many separate operational surfaces the team had to monitor.

In a Laravel-centric product, Reverb can bring broadcasting, authorization, queueing conventions, and monitoring into the same operating model. A separate Node.js service may introduce another deployment and authorization boundary, although that separation can also be an advantage for teams that operate it well.

The result table to publish after each run

Metric — Node.js socket service — Laravel Reverb — Change

Successful connections — report count — report count — calculate

Peak resident memory — report MiB — report MiB — calculate

Mean CPU — report percentage — report percentage — calculate

p50 delivery latency — report milliseconds — report milliseconds — calculate

p95 delivery latency — report milliseconds — report milliseconds — calculate

p99 delivery latency — report milliseconds — report milliseconds — calculate

Disconnect rate — report percentage — report percentage — calculate

Recovery after restart — report seconds — report seconds — calculate

The conclusion should never default to “Reverb wins.” State which implementation performed better for the disclosed cadence, fan-out, hardware, and failure profile.

What reduced the load

The migration included more than changing the WebSocket server. We also changed the event contract.

We stopped broadcasting every coordinate to every surface

Driver telemetry and customer-facing map motion do not need identical precision. Dispatch may need the raw operational stream. A customer waiting for an order usually needs a smoothed, rate-limited view.

The revised pipeline separated:

• raw location ingestion;
• persistence sampling;
• dispatch-room updates;
• customer-order updates;
• ETA recalculation;
• stale-driver detection.

Test raw fan-out, one visible update per second, and one visible update per five seconds. Keep ingestion, persistence, and customer-presentation rates separate.

This distinction must stay in the article because attributing all savings to Reverb would be misleading if payload coalescing produced part of the gain.

We made channel scope explicit

A city-wide driver channel is easy to demo and expensive to operate. Use order-, zone-, fleet-, or driver-specific channels so an update only reaches clients authorized to see it.

Reverb supports allowed-origin configuration, but origin checks are not a substitute for authenticated private-channel authorization. Driver and customer location data must be scoped at the application layer.

We planned for file descriptors before traffic

Long-lived connections consume open file handles. Laravel’s production guidance explicitly calls out open-file limits, process management, reverse-proxy configuration, event-loop support, and horizontal scaling. We treated those as deployment inputs rather than emergency fixes. (Laravel Reverb production guidance)

Where Node.js still makes sense

We did not leave Node.js because it cannot handle WebSockets. It can.

Node.js remains a reasonable choice when:

• the real-time service is already mature and independently operated;
• the team has strong Node observability and deployment tooling;
• events span multiple non-Laravel systems;
• the socket layer requires custom protocol behavior;
• independent scaling is more valuable than framework consolidation.

Reverb is a strong candidate when the application, authorization rules, queues, operations team, and deployment model are already Laravel-centric.

The architecture we would ship again

For a logistics product at this stage, our default shape is:

1. Driver app sends a timestamped coordinate with accuracy and motion metadata.
2. Laravel validates identity, freshness, range, and order assignment.
3. The ingestion path updates the latest-location store and queues durable history selectively.
4. Reverb broadcasts scoped events to authorized operations and order channels.
5. Redis coordinates fan-out when Reverb runs across multiple processes or hosts.
6. NGINX terminates TLS and proxies upgraded connections.
7. Pulse plus infrastructure metrics track connections and message volume; application traces track end-to-end delay.

The point is not to broadcast more coordinates. It is to move the minimum trustworthy state to the people who are allowed to see it.

Reproduce this before copying the conclusion

Publish the harness with these controls:

• fixed hardware and region;
• identical TLS behavior;
• identical payload and serialization;
• identical Redis placement;
• warm-up period excluded from the result;
• three or more runs per configuration;
• raw percentile output retained;
• reconnect storm tested separately;
• server and client timestamps synchronized;
• errors reported beside latency, not discarded.

A benchmark without the failure rate rewards the system that drops the most work.

Founder takeaway

Choosing a real-time stack from a framework logo is the wrong decision. Start with active connections, event cadence, fan-out, authorization boundaries, failure recovery, and the people who will operate the service at 2 a.m.

Your workload should have to earn the conclusion.

If you are scoping live driver, courier, or fleet tracking, App Clone Labs can turn the telemetry model into a benchmarkable architecture before it becomes a production bottleneck.