Why Is My Solana App Slow? Why Network Distance Matters
Why Is My Solana App Slow? Why Network Distance Matters
We often hear from traders and builders:
- “I’m running a similar strategy, but only my bot gets filled late.”
- “Prices update fine, but my transactions don’t make it in time.”
- “I’ve switched RPC providers, but the performance doesn’t really change.”
The first suspects in these situations are usually:
- “My code must be slow.”
- “My server specs probably aren’t good enough.”
Both of these can matter a lot.
But in a high-speed environment like Solana, there is an even more fundamental bottleneck that often shows up first: network distance.
But in a high-speed environment like Solana, there is an even more fundamental bottleneck that often shows up first: network distance.
On Solana, there are countless dApps, DeFi protocols, and markets running on-chain, and many of them rely on automated trading through bots. In what is effectively a high-frequency trading (HFT) environment, being able to detect events faster and execute faster than your competitors gives you an edge and a way to capture profit.
In this article, we will look at why network distance becomes a decisive factor when you aim for fast detection and low-latency execution on Solana, and how ERPC’s Bundle plans and VPS offerings are designed to address these needs.
Why does it feel like “only my app is slow”?
First, let’s organize some common situations:
- Your server has plenty of CPU and memory, but your trade reactions are still slower than the competition.
- You see new events via getProgramAccounts or log subscriptions, but your transaction submissions are always half a step behind.
- You have tried several cloud environments and multiple RPC providers, yet nothing feels like a breakthrough.
In these situations, many developers try to squeeze more performance out of their code or algorithms.
That is a valid and important effort, but there is a deeper structural issue that can remain unsolved:
That is a valid and important effort, but there is a deeper structural issue that can remain unsolved:
- You might be fighting from a “distant network” in the first place.
- From the viewpoint of the leader validator, your application might be located in a physically disadvantaged position.
If these conditions hold, no matter how much you refine your software, you will never fully reach the performance level you are aiming for.
To truly take advantage of Solana’s speed, you have to consider three layers together:
- Code
- Hardware
- Network
Among these, the first place you should often tune is “network distance”.
Three layers that determine speed
Code (software and strategy)
For bots and HFT-style systems on Solana, your code and strategy directly affect your results:
- Which events you use as triggers
- Under what conditions you enter and exit positions
- How much unnecessary I/O you remove, and how well you parallelize processing
These are the most intuitive optimization levers for many developers. Code-level improvements are essential, but they are only one piece of the puzzle.
Hardware
The next major factor is server performance. Having “enough capacity” is not enough on its own. You need to look at:
- High clock-speed CPUs (how fast a single core can process tasks)
- Core count (how many tasks can run in parallel)
- Memory capacity and memory channel count (whether large working sets can be accessed without stalls)
- Fast storage such as NVMe (so logging and data writes do not become a bottleneck)
Trading workloads often require handling large indexes and state. In that context:
- Large CPU caches
- Ample RAM with no risk of swapping
lead to more stable performance.
Of course, higher-performance environments cost more. In the end, you need a balance point where your strategy’s expected profit justifies the hardware investment.
Network
The most overlooked, yet often the most impactful factor for latency is the network.
With CPU optimization, you might be shaving off hundreds of nanoseconds to a few microseconds.
With network optimization, the difference you can achieve may suddenly be in the range of hundreds of milliseconds. In terms of magnitude, network changes can have a thousand times more impact.
With network optimization, the difference you can achieve may suddenly be in the range of hundreds of milliseconds. In terms of magnitude, network changes can have a thousand times more impact.
Even if you have:
- A powerful server
- Efficient software
- A well-designed strategy
putting your resources in the wrong network location will nullify much of the effort. The first move should be to choose the right data center and the right network for your app.
Regaining intuition about network distance
Because networks are not visible in the same way as CPU or RAM, it is hard to build intuition about them. To make it easier, it helps to think in terms of transportation.
When you think about the internet, imagine:
- Your server as the departure point
- The Solana validator or RPC endpoint as the destination
and picture travelling by car or plane between those points.
Short-distance trips:
- Have fewer traffic lights and intersections
- Are less exposed to congestion
- Have little variation in arrival time and usually stay on schedule
Long-distance trips:
- Require highways, tunnels, and hub airports
- Go through many intermediate points
- Are more easily affected by construction, accidents, or traffic jams
As a result, arrival times vary much more.
Networks behave the same way:
- Shorter fiber cables
- Fewer intermediate routers and switches (intersections and hubs)
mean shorter round-trip times and less jitter.
Bandwidth (1Gbps, 10Gbps, 25Gbps) is like the number of lanes on a road.
More lanes allow more data to flow in parallel and reduce congestion. But even with many lanes, if the route is overly long or indirect, the total travel time will still be large.
More lanes allow more data to flow in parallel and reduce congestion. But even with many lanes, if the route is overly long or indirect, the total travel time will still be large.
On Solana, if you want real speed, you need both:
- Enough lanes (bandwidth)
- Short distance and efficient routes
How Solana’s structure amplifies the effect of distance
On Solana, blocks are produced by leader validators that rotate every slot, with leaders located around the world.
Today, many validators are clustered in regions such as Frankfurt. However, even so, leaders move around:
- Frankfurt
- New York
- Tokyo
- Singapore
and other regions across the globe.
In this structure:
- When a leader is in Frankfurt, nodes inside the Frankfurt network are at a clear advantage.
- When a leader is in Tokyo, nodes near Tokyo are at an advantage.
This is a very simple but very powerful reality.
Intercontinental communication commonly costs over 100ms in round-trip ping alone. For example:
- Chasing a Tokyo leader from Frankfurt
- Chasing a New York leader from Tokyo
means that when you include Shreds stream reception and processing, your effective detection timing can easily be delayed by 1000ms or more. For trading and monitoring applications, that time gap is enormous.
Why chasing average latency is not enough
The first metrics many users look at are:
- Average ping
- Average response time
These are useful, but on a network like Solana where leaders move across the globe slot by slot, there is a big difference between:
- Having a good average
- Being fast at the specific moments when it matters
Even if a certain setup shows an average latency of 200ms, in reality you might be seeing:
- 20ms in some slots
- 600ms in other slots
For 0-slot trading or any strategy that relies on being within a 200–400ms window, what matters is not the average:
- It is whether you can operate with low latency
- At the exact moments
- Within your target region
Whenever you are trying to hit leaders that are located on another continent, there will be slots where you are physically unable to keep up.
If you focus only on average latency and ignore this reality, you will remain stuck in the “I don’t know why I’m losing” zone.
Isolating where your app is actually slow
From here, let’s look at how to identify where your application is losing time.
Measure your current latency
First, measure the distance to your current endpoints as numbers, not feelings.
- Your current RPC / gRPC / Shredstream endpoints
- Nodes located in the same region as those endpoints
Run ping tests against them and record the round-trip baseline.
Do not rely on a single measurement.
Run multiple pings in short intervals and look at the median instead of just the mean. This gives a better picture of that day’s “road conditions”.
Run multiple pings in short intervals and look at the median instead of just the mean. This gives a better picture of that day’s “road conditions”.
Separate network time from app processing time
Within your app, record:
- Request send timestamps
- Response receive timestamps
- Start and end times of internal processing
Then, separate:
- How much time is spent on network round-trips
- How much time is spent on your actual business logic
In many cases, you will find:
- Your code is finishing in a few milliseconds to a few tens of milliseconds
- Network round-trips are consuming hundreds of milliseconds
Typical bottleneck patterns
Some common patterns include:
- Using the same RPC endpoint from all over the world
- Connecting from home or office through multiple layers of VPNs and proxies
- Hosting servers in a single region and trying to chase every leader around the globe from there
In these setups, Solana’s structure almost guarantees that you will always be attacking some leaders from a disadvantaged position.
Designing with network distance on your side
To make network distance work for you, rather than against you, there are several key steps.
Decide which network you are actually fighting in
For Solana, the “network” you care about is the one built by validators.
The frequency of leader slots is proportional to the amount of stake, so:
The frequency of leader slots is proportional to the amount of stake, so:
- Networks that host validators with large stake
effectively become “primary networks” in practice.
Start by understanding:
- Which regions are close to the markets or dApps that matter for your strategy
- How you plan to cover stake-heavy regions such as Frankfurt
This is how you decide which networks you actually want to fight in.
Data center and network selection
For Solana workloads, it is crucial to know whether:
- You are in the same data center as key validators or Jito Block Engine
- Or connected to them via PNI (Private Network Interconnect)
The internet is global, and in principle, your app will “work” no matter where you put it.
However, for HFT or near-real-time detection, the main questions become:
However, for HFT or near-real-time detection, the main questions become:
- How much external network traffic can you eliminate?
- How close can you get to a zero-distance configuration?
These choices create the first major performance gap.
Stepping into multi-region architectures
In the ideal world you would have presence everywhere, but you do not need to cover all regions from day one.
A practical first step is something like:
- Frankfurt (major network)
- Plus one more region that is important to your strategy (New York, Tokyo, Singapore, etc.)
From a small number of regions you can gradually expand.
At each region, you:
- Receive Shreds and gRPC locally
- Complete processing locally, or forward over your own network via the shortest possible path
This makes it much easier to maintain a state of “being the fastest somewhere at any given time”.
ERPC’s network design and how Bundle / VPS fit in
Now, let’s map the above ideas to ERPC’s design and product lineup.
Solana-focused networks and PNI-based architecture
ERPC is built as a network specialized for Solana. We carefully select:
- Regions where stake is concentrated
- Data centers that host major validators and Jito Block Engine
- Data centers that are directly connected via PNI to those core locations
to construct a topology that can deliver maximum output for Solana workloads.
The internet is global, and your app will run no matter where you deploy it.
But when you care about HFT or fast detection, you must first get data center selection and network selection right. ERPC is designed specifically to address that problem for Solana.
But when you care about HFT or fast detection, you must first get data center selection and network selection right. ERPC is designed specifically to address that problem for Solana.
Ping-based automatic routing
For shared Solana RPC endpoints, ERPC does not rely on IP geo-location.
Instead, we:
Instead, we:
- Automatically measure ping from each region to every whitelisted IP
- Choose the closest region based on actual measurements
This avoids issues such as:
- Routes that look close on a map but are actually long detours
- Routing decisions based on outdated geo-location databases
and ensures you always connect via the shortest path we can measure in practice.
Solana RPC Bundle plans
The Solana RPC Bundle plans give you:
- RPC (HTTP / WebSocket)
- Geyser gRPC (no filter restrictions)
- Shredstream gRPC
in a single package.
Most teams start their real-time Solana journey with Geyser gRPC. Since it delivers already decoded data:
- Implementation is simpler
- There are many examples and references
- The learning curve is relatively gentle
Meanwhile, professional teams add Shredstream to push detection and execution closer to the leading edge.
With Bundle:
- You can keep your existing production RPC / gRPC setup
- You can add Shredstream without a big extra cost
The pricing is designed to let you:
- Build a stable base application using RPC + gRPC
- Then, in that same environment, start experimenting with Shredstream and gradually move into higher performance
All without stopping your production systems.
EPYC VPS / Premium Ryzen VPS
To push network distance even further down, ERPC also provides VPS offerings within the same network as ERPC endpoints.
The lineup includes:
- EPYC VPS for strong cost-performance
- Premium Ryzen VPS built on 5.7GHz Ryzen CPUs
These environments provide:
- High clock-speed CPUs
- ECC DDR5 memory
- NVMe4 storage
- 25Gbps × 2 networking
all tuned for Solana workloads.
These VPS instances run in the same network as:
- Jito Block Engine
- Shredstream nodes
- Geyser gRPC nodes
This “zero-distance” setup allows you to run your applications near the leaders without crossing external networks.
By combining Bundle plans with these VPS offerings, you can jointly optimize:
- Network distance
- Hardware performance
- Stream quality
and build a solid foundation for latency-sensitive use cases.
Where to start (checklist)
Here are steps you can take right after finishing this article:
-
Measure ping to your current RPC / gRPC / Shredstream endpoints
Do this multiple times over a short period and look at the median, not just a single sample. -
Add logging in your application to separate network time from processing time
Measure request send → response receive, and the internal processing done between those two points. -
Check which regions are actually close to your target markets or dApps
If possible, measure ping from multiple candidate regions so your decisions are based on data, not just intuition. -
Deploy a single VPS or Bundle in a region close to your key targets and run comparison tests
Log and compare how much your latency improves compared to your existing environment. -
Expand to a multi-region architecture as needed
For example: Frankfurt + New York, Frankfurt + Tokyo, or Frankfurt + Singapore, depending on your strategy. -
Over the longer term, collect data about leader schedules and validator locations
Build up your own understanding of which regions are advantaged at which times, and continuously tune your network layout based on epoch-by-epoch changes.
Summary: why you should start with network distance
If you want to build fast trading or monitoring systems on Solana, you need to think about code, hardware, and network at the same time. Among these, network distance is:
- One of the largest levers for improvement
- One of the most commonly overlooked sources of latency
As long as you are chasing leaders from faraway networks, there will always be slots where you are physically unable to win, no matter how optimized your code and servers are.
That is why you should:
- Measure your network distance properly
- Understand which networks you are really fighting in
- Move your applications to locations that make sense for Solana
These are the first steps toward true performance.
ERPC and Validators DAO provide Solana-focused networks and server resources to make these architectures realistic and accessible in practice.
If you would like to discuss network distance optimization or how to structure your Bundle and VPS setup, feel free to reach out via the Validators DAO official Discord.
- ERPC official site: https://erpc.global/en
- Validators DAO official Discord: https://discord.gg/C7ZQSrCkYR
