# Solana gRPC Best Practices

The Solana Yellowstone geyser gRPC stream is the most direct and efficient way to access real-time data from the Solana blockchain. To truly harness its power for high-frequency trading, arbitrage, or real-time analytics, developers must optimize both their infrastructure and client-side logic. Here are few of the best practices that Shyft suggests.

### Minimize Your Ping <a href="#grpc-ping" id="grpc-ping"></a>

Latency starts at the network level. No matter how optimized your code is, the speed of light remains the ultimate bottleneck. The single most impactful action you can take to minimize latency is to achieve geographical **co-location** with Shyft gRPC's endpoint.&#x20;

{% hint style="success" %}
Aim for a network latency of **0-1 milliseconds** (ms) between your client application and Shyft gRPC URL.
{% endhint %}

Here are the data centers **Shyft** use for different regions which you can co-locate with.

* **Amsterdam:** Cherry Servers
* **Frankfurt:** Cherry Servers, Latitude
* **London:** Latitude
* **New York:** Latitude
* **Ashburn:** Latitude

Its still possible to achieve **1-2 ms** latency without co-locating. Make sure you are in the same region as the gRPC URL you are connecting to. Use standard network tools like `ping` or `mtr` to measure your latency.

{% hint style="info" %}
**Suggestion:** While our shared infrastructure is built for high reliability, applications requiring extreme precision can unlock a 5-10ms latency boost by switching to [Shyft Dedicated gRPC Nodes](https://shyft.to/solana-dedicated-grpc-nodes). This specialized service is reserved for our paid users, providing the best data streaming performance on Solana via private, 1:1 hardware allocation.
{% endhint %}

### Distribute Load Across Multiple gRPC Clients

Streaming multiple high-load addresses (e.g., Meteora DLMM, Pumpfun, etc) in a single Geyser `subscribe` request can quickly overwhelm a single client connection. This can lead to&#x20;

A backlog of messages waiting to be processed at the network layer within the client's single consumer thread. The client may fall too far behind, causing the provider or client library to disconnect to prevent unmanageable backlogs.

{% hint style="success" %}
Shyft suggests splitting high-load addresses across multiple gRPC clients and distribute their processing across separate CPU cores/threads.
{% endhint %}

* For extremely high-volume programs (e.g., DEXs, Pump.fun), divide the stream load across multiple gRPC clients. This horizontally scales your processing to prevent a single client from becoming a bottleneck.
* Moreover, ensure different streams are processed on different threads or cores (or using an asynchronous event loop) to decouple I/O (receiving the message) from CPU-bound work (deserializing, filtering, and executing business logic). This prevents slow processing logic from delaying the consumption of new messages off the network buffer.

### Connection Efficiency

While horizontal scaling is necessary for high-load programs, over-fragmenting your connections for moderate-load addresses can quickly hit your Shyft connection limits.

{% hint style="success" %}
Dont create a new connection for token, pools or wallet addresses. Club them together in a single subscribe request.
{% endhint %}

For moderate-load addresses (e.g., individual tokens, liquidity pools, or user wallets), it is significantly more efficient to club multiple addresses into a single Geyser `subscribe` request. Instead of having a new connection for each individual address.

[<mark style="color:red;">Learn how to Modify your gRPC subscribe request to add or remove addresses.</mark>](https://docs.shyft.to/solana-yellowstone-grpc/docs/getting-started/modify-grpc-subscribe-request)

### Expand gRPC Max Decoding Message Size

Yellowstone gRPC clients have a default maximum size for a single incoming message, which is **4 MB (4194304 bytes)**. If you are streaming account update or block udpates there are chances that you can hit the 4 MB limit.&#x20;

{% hint style="success" %}
Configure your gRPC client while initialising to avoid hitting the 4 MB message limit.
{% endhint %}

To avoid this, you need to configure your gRPC client initialisation

{% tabs %}
{% tab title="TS" %}

```typescript
const client = new Client(shyft_grpc_url, shyft_grpc_token, {
  "grpc.max_receive_message_length": 1024*1024*1024
});
```

{% endtab %}

{% tab title="Rust" %}

```rust
async fn connect(&self) -> anyhow::Result<GeyserGrpcClient<impl Interceptor>> {
        GeyserGrpcClient::build_from_shared(self.grpc_url.clone())?
            .x_token(Some(self.grpc_token.clone()))?
            .connect_timeout(Duration::from_secs(10))
            .timeout(Duration::from_secs(10))
            .tls_config(ClientTlsConfig::new().with_native_roots())?
            .max_decoding_message_size(1024 * 1024 * 1024)
            .connect()
            .await
            .map_err(Into::into)
    }
```

{% endtab %}
{% endtabs %}