Bot Trading için VDS’de düşük gecikme nasıl sağlanır?

Bot trading’de performansı belirleyen tek şey “CPU güçlü mü?” değildir. Alım-satım mantığınız hızlı olsa bile; ağ gecikmesi (latency), saat senkronu hataları ve DNS/bağlantı kurulum süreleri sonuçları doğrudan etkiler. Bu rehberde VDS üzerinde düşük gecikmeyi sistematik şekilde kurmak için hangi ayarların ne işe yaradığını, hangi ölçümlerle doğrulayacağınızı net adımlarla anlatıyorum.

Hedef: VDS’inizi doğru lokasyona almak, ağ yolunu daraltmak, zaman senkronunu düzeltmek ve uygulama katmanında gereksiz beklemeleri sıfıra yaklaştırmak.

1) Düşük gecikme için önce ağ yolunu “kısaltın”

Bot trading’de gecikme; genellikle (i) veri merkezinize erişim (WAN → DC), (ii) platform API uçlarına gidiş-dönüş, (iii) aynı makinedeki süreçlerin zamanlama hassasiyeti ve (iv) bağlantı kurulum/yeniden deneme davranışlarından oluşur.

Türkiye’den borsa/exchange’e yakınlık: tek kriter değil

Sunucu lokasyonu tek başına tüm sorunu çözmez; ama çoğu senaryoda ilk kazanım buradan gelir. Örneğin Türkiye’deki kullanıcılar için Avrupa merkezli veri merkezleri ile TR arasında RTT farkı belirgindir. Aynı exchange’in farklı bölgelerde edge (uç) sistemleri varsa, “en yakın ama aynı zamanda tutarlı” lokasyon seçmek gerekir.

NetKıyas’ta kontrol edebileceğiniz sağlayıcı seçeneklerinden bağımsız olarak, karar kriteri şu olmalı: - Exchange/API endpoint’inin bulunduğu bölge ile VDS lokasyonunuzun coğrafi yakınlığı - Aynı ISP/rotaların tutarlılığı (her gün rota değişiyorsa latency jitter artar) - IPv4/IPv6 erişim yolu (bazı sistemlerde IPv6 daha hızlı ama daha riskli olabilir)

Gece/gündüz jitter’ı ölçün

Bot trading’de ortalama latency kadar jitter (dalgalanma) da önemlidir. Jitter yüksekse karar mantığı daha sık yanlış tetiklenir. - En az 24 saat boyunca RTT ölçümü yapın. - Ölçümde minimum, maksimum ve 95. yüzdelik dilim (p95) değerlerini birlikte değerlendirin.

2) VDS’de ağ performansı: planı, gereksinimi ve “limitleri” netleştirin

Düşük gecikme için VDS seçerken “sınırsız trafik” gibi pazarlama terimleri yerine, ağ throttling (ağ hız kısıtlama) ve kaynak paylaşımı davranışını anlamak gerekir.

Kontrol edilecek teknik başlıklar

Aşağıdaki maddeler VDS sözleşmesi ve panel/teknik dokümanda net yazılmalıdır: - Paylaşımlı ağ mı ayrılmış ağ mı? (dedike/garanti bant mı yoksa best-effort mı?) - Outbound (çıkış) trafik sınırlaması var mı? - Akıllı throttling veya saatlik bant kısıtı var mı? - Paket kaybı (packet loss) raporlanıyor mu? - IPv4/IPv6 için ayrı performans/rota var mı?

Net kontrol listesi (satın alma öncesi): - VDS’inizin “aynı host üzerinde başka müşterilerle kaynak paylaşımı” oranını sağlayıcı açıklıyor mu? - “Network Throttling” uygulanıp uygulanmadığını sağlayıcı dokümanla doğruluyor mu? - Replikasyon/backup trafiği dönemsel olarak ağınızı meşgul edecek mi?

VDS spec’leri: CPU’dan önce network

Bot trading iş yükleri genellikle: - Websocket/HTTP bağlantıları - JSON parse/serileştirme - Küçük hesaplar + emir gönderimi - Loglama/yedekleme

Bu tip işlerde CPU tek başına belirleyici değildir. Asıl belirleyici genelde: - NIC (network interface) kalitesi - Packet loss ve jitter - Node başlatma ve container/process davranışı

Bu yüzden VDS’i seçerken “yeterli CPU + düşük gecikme odaklı ağ” yaklaşımı doğru olur.

3) Zaman senkronu (NTP/PTP): bot kararlarını düzeltir

Bot trading’de gecikme sadece ağ değil; zaman damgası (timestamp) doğruluğu da performansı etkiler. Exchange tarafı ile senkron bozukluğu varsa, loglarınız “geç geldi/erken gitti” gibi yanlış yorumlara yol açar.

Yapılacaklar

VDS üzerinde NTP (Network Time Protocol) düzgün çalışmalı.
Uygulamanızın kullandığı sistem saatinin UTC olmasına dikkat edin.
Frekans sapması ve drift’i kontrol edin.

Örnek doğrulama mantığı: - Sistem saati servisleri aktif mi? - NTP sunucusu doğru mu? - Yeniden başlatma sonrası saat sapması büyüyor mu?

Bu adım “gecikmeyi azaltma” kadar, gecikme ölçümünüzü güvenilir kılar.

4) Uygulama katmanında gecikmeyi düşürün: bağlantı, DNS ve yeniden denemeler

Ağ gecikmesi kaçınılmaz olsa da, uygulama katmanındaki gereksiz beklemeler azaltılabilir.

DNS: önbellekleme ve kısa çözüm süreleri

DNS çözüm süresi (resolution) ilk bağlantılarda veya cache bozulduğunda gecikme yaratır. - Uygulamanız veya sistem DNS cache kullanıyor mu kontrol edin. - “Her istek için DNS çöz” davranışını kaldırın. - DNS TTL’leri değişiyorsa uygulama tarafında yeniden çözüm stratejisini netleştirin.

Bağlantı kurulumu: keep-alive ve pooling

HTTP kullanıyorsanız keep-alive (kalıcı bağlantı) etkin olmalı.
Tekrarlı isteklerde TCP/TLS handshake’i her seferinde tekrar etmemelisiniz.
Websocket kullanıyorsanız reconnect stratejisi jitter’ı artırmayacak şekilde planlanmalı.

Yeniden deneme (retry) davranışı: botu yavaşlatmasın

Retry mekanizmaları yanlış kurulursa gecikmeyi büyütür: - 429/5xx durumlarında lineer değil, kontrollü backoff kullanın. - Retry sayısını sınırlayın. - Retry’nin “eşzamanlı” değil “planlı” ilerlediğini doğrulayın.

5) Kernel ve kaynak ayarları: gecikme yerine “dalgalanmayı” azaltın

Düşük gecikme hedefinde çoğu kişi yalnız “ortalama latency”ye odaklanır. Oysa bot trading için jitter ve sistemin beklenmedik şekilde gecikmesi (scheduler gecikmesi) daha tehlikelidir.

CPU scheduler ve I/O davranışı

Uygulamanızın gecikmesini artıran yaygın kök nedenler: - Aynı CPU çekirdeğinde yoğun başka süreçler - Disk I/O’nun beklenmedik şekilde artması (log/backup) - Swap kullanımı (memory pressure)

Bu nedenle: - Uygulama process’lerini gereksiz yükten ayırın. - RAM yeterliliğini sağlayın; swap’a düşmek jitter’ı artırır. - Loglama stratejisini gözden geçirin (aşırı disk yazımı vs.).

Düşük gecikme için pratik yaklaşım

Uygulamanızı gerçekçi yükle test edin.
CPU/RAM/disk I/O metriklerini eş zamanlı izleyin.
Packet loss ve retransmit loglarını ayrı tutun.

6) Ölçüm olmadan optimizasyon yapmayın: veriyle karar verin

Düşük gecikme optimizasyonunun kritik kısmı “ölçüm tasarımıdır”. Sadece ping görmek yetmez; emir gönderimi ile exchange ack’i arasını uygulama seviyesinde ölçmelisiniz.

Uygulama tarafı metrikleri

Şu metrikleri standartlaştırın: - Exchange mesaj alma → karar → emir gönderme zamanı (pipeline time) - Emir gönderme → kabul/ack zamanı - Websocket reconnect sayısı ve süresi - Retry sayısı ve toplam retry süresi

Sistem tarafı metrikleri

CPU throttling (varsa)
Disk I/O wait
Ağ arayüzünde packet loss / retransmit göstergeleri
Memory pressure (OOM riski / swap)

Karşılaştırma yöntemi (net test planı)

1-2 gün “baseline” ölçüm alın.
Tek değişken yapın: örneğin DNS cache ayarını güncelleyin.
6-24 saat tekrar ölçün.
Farkı p95/p99 (yüksek kuyruk) seviyesinde görün.

7) En yaygın hatalar: bot trading’i yavaşlatan 10 nokta

Aşağıdaki hatalar sık görülür ve “spec yüksek ama bot yine de yavaş” durumuna yol açar.

VDS lokasyonu exchange’e uzak seçilmesi
DNS her istek öncesi çözülüyor olması
keep-alive/pooling kapalı kalması
Yanlış retry/backoff ile anlık trafik patlaması
Swap kullanımı (memory pressure)
Diskte aşırı loglama (özellikle senkron yazım)
Tek process’in CPU’yu tek çekirdeğe kilitlemesi
NTP yanlış yapılandırması (timestamp sapması)
Websocket reconnect storm (toplu yeniden bağlanma)
Yalnızca ortalama latency’ye bakılması (jitter göz ardı)

Hız odaklı VDS kurulum kontrol listesi (kısa ve uygulanabilir)

Lokasyon: Exchange/API endpoint’ine en yakın ve rota tutarlılığı iyi lokasyonu seçin.
Ağ: Packet loss/jitter odaklı test yapın; network throttling riskini netleştirin.
Zaman: NTP aktif, saat UTC ve drift kontrol ediliyor.
DNS: DNS çözümünü cacheleyin; TTL değişimlerine uyumlu strateji kurun.
Bağlantı: HTTP keep-alive + pooling; websocket için reconnect stratejisi planlı.
Kaynaklar: Swap’a düşmeyin; loglama disk I/O’yu boğmasın.
Ölçüm: p95/p99 latency, pipeline time, ack time ve reconnect/retry metriklerini toplayın.

Sonuç: düşük gecikme için “tek hamle” değil, ölçümlü optimizasyon yapın

Bot trading için VDS’de düşük gecikme; lokasyon, ağ kalitesi, zaman senkronu ve uygulama bağlantı ayarlarının birlikte doğru kurulmasıyla düşer. Bugün yapacağınız en somut aksiyon sırası şudur: önce baseline ölçümü alın, sonra VDS lokasyon/ağ seçimini doğrulayın, ardından DNS + keep-alive/retry stratejisini düzenleyin ve son olarak NTP ile saat sapmasını sabitleyin. Bu sırayla ilerlediğinizde gecikmeyi sadece “tahminle” değil, p95/p99 metriklerinde ölçerek düşürdüğünüzü görebilirsiniz.