Performance

Performance

Due to VeloSim being like a real-time simulator (accurate to the real world second), performance is one of the most important aspects of the software. Performance can be understood in different aspects such as:

UX Performance:

• When the client uses the application, they must achieve their goal as smoothly as possible.
• There will be a lot of animations and moving items on the screen. This must be smooth and responsive.
• When the actors interact with the simulator through the front-end, they should not be overwhelmed by an extreme amount of data.
• Visual feedback should be immediate, with minimal perceived delay between user actions and system response.

API Performance:

• It is not just about how well it works but also knowing what it does.
• Response times should be consistent and predictable to ensure smooth integration with the front-end.
• Endpoints must handle high request volumes without degradation in performance.

Parallel Simulations:

• The client requests to have multiple simulations running in parallel per user.
• Given this, there could then be many users that will host many simulations, which can explode in resource utilization.
• Resource allocation and isolation between simulations is critical to prevent interference.

Generating Routes and Representing Real Time:

• Route generation must be fast enough to maintain the real-time aspect of the simulation.
• Hardware resources will need to hold and process large amounts of map data efficiently.
• Real-time updates must be synchronized across all active simulations without lag.

Client Satisfaction

• Ensuring that the client is happy with our team performance and progress.

Network Latency and Lag

• Minimizing network latency is essential for maintaining the real-time nature of the simulator.

System Requirements:

• It is expected that the simulator will require some above average hardware specs.

Formula for Success:

Release 1 will focus on delivering the minimal functional prototype, which optimizations are ready to be improved. The goal of release 1 is to allow the client to understand the basic functionality of the system. We will evaluate the feedback, and then begin gathering and implementing deeper performance metrics, based on the wishes of the client.

Release 2 will focus on implementing more functionality, while enhancing mainly the critical aspects of the previously implemented features and their performance. About 85% of the features should be completed by the end of this release.

Release 3 will focus on completing the remaining user stories, but mainly focusing on performance, bug fixes, enhancements, logging and A/B testing. By then, we will have a lot of time to discuss with the stakeholder and focus on the performance.

Release 1 Notes:

Simulator allows to start a simulation, allows to dispatch tasks via assigning and reassigning, with a simulation configuration file. In the scope of performance, the most crucial aspect is loading up a simulator, calculating a route and updating a lot of data between the client and server.

Keyframes and Diff Frames:

Keyframes differ from diff frames in that, a keyframe contains every bit of information of entities that exist in a simulation instance, while diff frames only contain information that has changed since the previous frame was emitted.

In order to minimize the amount of data sent over the websocket, the simulator only emits key frames during the first emission, final emission, and at a frequency specified in the sim instance initialization. In every other case, only diff frames are emitted, to avoid redundant data being sent over the websocket connection.

Calculating Routes:

When finding the nearest positions (to a valid coordinate in the map), and then calculating the path, at first, the time taken was about 10 seconds. This is because the map is encoded in a graph data structure.

It took about 10 seconds to generate a route. This is because the encoding of the positions is in nodes/edges, and to find it takes time. And the route generation took even more time due to the millions of combinations possible. To optimize this, we used KD trees to encode the nodes, which is like a binary search tree. This allows us to find the nodes very quickly. This reduced the time to about 1-2 seconds. But generating the path was still a culprit. After research, we used contraction hierarchies, which is an algorithm dedicated to vehicle navigation applications. After applying it, we reached a total time of 0.01 seconds to calculate everything. OSRM was validated as a strong plug-and-play routing engine for baseline performance, but its single-traffic-state limitation became a bottleneck for concurrent, traffic-aware simulations.

---

Release 2 Notes

• OSRM was investigated and reduced route generation to milliseconds.
• As documented in the Routing - Traffic Engine Research, OSRM's single active traffic state became a scaling constraint for multi-simulation workloads; state swapping introduced about 2 seconds of overhead.
• This drove the Release 3 routing transition to a provider better suited for per-request traffic behavior.

---

Release 3 Notes

• Routing stack transitioned to GraphHopper as the active provider for traffic-aware simulations (#752, #882).
• GraphHopper custom-model routing removed the need for OSRM-style traffic-state swapping and improved support for concurrent simulation scenarios.
• Scheduled route recalculations were added to better handle dynamic traffic updates without forcing full route recomputation at every step (#884).
• Observability dashboards (Prometheus + Grafana) were used to track p95 latency, throughput, CPU, and memory trends across deployments; this improved regression detection and triage speed.
• Production observations showed CPU spikes under peak simulation activity remain the dominant performance risk, while memory behavior remained stable (no sustained leak pattern observed).
• Frontend telemetry remained mostly stable with low error rates, but intermittent WebSocket connection errors were identified as a reliability/performance-adjacent issue to continue addressing.