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

Bot trading’de hız tek başına kâr getirmez; bekleme ise doğrudan fırsat kaybına dönüşür. Bu yazıda VDS (Virtual Dedicated Server) üzerinde botunuzun gecikmesini düşürmek için ölçülebilir adımları ele alıyoruz. Odak; veri yolunu kısaltmak, ağ sürtünmesini azaltmak, zaman senkronunu sağlamlaştırmak ve performansı sayılarla doğrulamaktır. Okuduktan sonra “hangi ayar ne kazandırır?” sorusuna net bir kontrol listesiyle yanıt vereceksiniz.

1) Gecikmenin nerede oluştuğunu önce ayırın (ölçmeden optimizasyon olmaz)

Bot trading gecikmesi tek kaynaktan gelmez. Tipik olarak şu bileşenlere ayrılır:

• Network RTT (ping): İstek-yanıt gidiş-dönüş süresi.
• DNS çözüm süresi: Domain isimlerinin IP’ye çevrilmesi.
• TCP/TLS kurulum süresi: Bağlantının ilk açılışı (handshake).
• Uygulama kuyrukları: Botun aldığı mesajı işleyene kadar geçen süre.
• Ticaret entegrasyon gecikmesi: Borsa/işlem sağlayıcı API’si, rate-limit ve cevap işleme.
• Disk/OS etkileri: Log yazma, yoğun okuma/yazma, swap kullanımı.

Önce hedefinizi netleştirin: “emir gönderme” mi yoksa “piyasa verisini alma” mı daha kritik? Sonra ölçüm setini buna göre kurun. Aksi halde hem yanlış noktaya optimizasyon yaparsınız hem de iyileşmeyi görmezsiniz.

Hız metriklerini tek yerde toplayın

Aşağıdaki yaklaşım botunuzu sayısal olarak yönetmenizi sağlar:

• Zaman damgası (timestamp) farkını uygulama içinde loglayın:
• Mesaj alındı zamanı
• İşlendi zamanı
• Emir gönderildi zamanı
• Emir yanıtı zamanı
• Ping/trace ile ağ katmanını doğrulayın:
• ping ile paket kaybı (loss) ve jitter (dalgalanma) kontrolü
• traceroute veya mtr ile rotadaki darboğazları görün
• Uygulama profilini çıkarın:
• Python/Node/Go tarafında olay döngüsü tıkanıyor mu?
• JSON parse, veri dönüştürme, gereksiz yeniden denemeler var mı?

Bu adımın sonucu şu olmalı: Gecikmenin çoğu “ağ”dan mı geliyor yoksa “uygulama” mı baskın?

2) VDS konumu: RTT’yi düşürmenin en doğrudan yolu veri yolunu kısaltmaktır

Gecikme optimizasyonunun en hızlı getirisi genellikle “yanlış lokasyonda VPS açmak” sorununu düzeltmektir. Bot trading’de borsanın/işlem sağlayıcının servisleri ile VDS’iniz arasında gereksiz mesafe ve rota karmaşası gecikmeyi büyütür.

Hangi ülke/şehir? (net karar ölçütleri)

Aşağıdaki kontrolleri yapın:

• VDS’in veri merkezinin lokasyonu, kullandığınız piyasa veri sağlayıcısının endpoint’lerine yakın olsun.
• Aynı sağlayıcıyla farklı bölgelerde deneme yapın:
• 1-2 saatlik ölçümde ortalama RTT ve %95 gecikme (p95) değerlerini kıyaslayın.
• “Daha yakın = daha iyi” varsayımı tek başına yeterli değil; rota kalitesi önemlidir. O yüzden tracer/tcp ölçümü yapın.

İstanbul vs Ankara gibi şehir farkları

Türkiye içinde veri merkezi seçimi bile RTT ve jitter üzerinde etkili olabilir. Eğer borsanın API endpoint’i yurt dışındaysa yerel şehir farkı tek başına mucize yaratmaz; ancak uygulama tarafında oluşan zamanlama hassasiyeti (ör. seri emir yönetimi, mesaj kuyrukları) için jitter azaltımı fayda sağlar.

3) Ağ ve bağlantı kurulumunu azaltın: DNS, TLS ve bağlantı stratejisi

VDS tarafında “ilk bağlantı” gecikmesi ciddi fark yaratabilir. Botunuz her emir için yeni bağlantı açıyorsa toplam gecikme büyür.

DNS’i kararlı yapın

DNS gecikmesi dalgalanabilir. NetKıyas gibi karşılaştırma platformlarında IP/konum tartışılır; burada siz çözüm zamanını azaltmaya odaklanın.

Uygulanabilir net adımlar:

• Botunuzu çalıştırdığınız sistemde DNS caching kullanın.
• Endpoint domain’i sabitse, DNS çözümünü periyodik değil, gerektiğinde yenileyin.
• Çok kritik senaryolarda (deneysel) endpoint’i IP üzerinden sabitlemeyin; IP değişebilir. Bunun yerine kısa TTL’li DNS ile caching stratejisini yönetin.

TLS/HTTP bağlantılarını yeniden kullanın

Bot trading senaryolarında iki uç yaygın:

• Sürekli bağlantı (WebSocket): piyasa verisi için
• İstek/yanıt (REST/gRPC): emir gönderme için

REST isteklerinde her seferinde yeni bağlantı kurmak yerine:

• Keep-Alive / connection pooling kullanın.
• HTTP/2 veya uygun kütüphaneyle multiplexing’den yararlanın.
• TLS oturumlarının tekrar kullanımını destekleyen ayarları doğrulayın.

Net hedef: “emir gönderme” akışında TLS handshake sürelerinin loglarda görünmediğini veya belirgin şekilde azaldığını görmek.

4) İşlem hattını sıkılaştırın: CPU, RAM, iş parçacıkları ve disk gecikmesini kontrol edin

Gecikmenin önemli bir kısmı network’ten değil; botun işletim sistemi üzerinde “geç işlenmesinden” gelir.

CPU planlaması: pinning ve kaynak ayırma

• VDS planı seçerken tek çekirdek performansı ve kararlı CPU tahsisi kritik olabilir.
• Botu çalıştırdığınız süreçte gereksiz thread sayısını azaltın.
• Aynı anda çalışan ek işler (log işlemcisi, raporlama, başka botlar) varsa öncelikleri ayırın.

RAM ve swap: sayfa hatalarını (page fault) azaltın

Swap devreye girerse latency sıçrar. Net kontrol:

• Botun çalışma seti (working set) RAM’de kalsın.
• free -m ile RAM durumunu ve vmstat ile swap aktivitesini takip edin.
• Logları disk yazıp sonra ayrı bir süreçte işlemek yerine, log yazma yükünü de yönetmeniz gerekir.

Disk I/O: log yazmayı optimize edin

• Logları çok sık ve senkron (synchronous) yazmak gecikme yaratabilir.
• Uzak disk (network storage) yerine yerel NVMe/SSD kullanan VDS tercih edin.
• Loglar için tampon (buffer) kullanın, günlükleri döndürün (log rotation).

Bu bölümün doğrulaması şudur: Uygulama “işlendi” zamanı ile “emir gönderme” zamanı arasındaki farkta disk/OS kaynaklı sıçramalar azalır.

Basit doğrulama tablosu

Aşağıdaki tablo, optimizasyon sonrası beklentinizi netleştirir:

5) Zaman senkronu ve olay sırası: trading botunda saat hatası maliyet demektir

Bot trading’de “olay sırası” ve zaman damgası kritik olabilir. Özellikle birden fazla akış (market data + risk + execution) aynı anda çalışıyorsa saat senkronu doğrudan sorun çıkarır.

NTP/PTP ile zaman tutarlılığı

• VDS işletim sisteminde NTP servisinin doğru çalıştığını doğrulayın.
• Zaman damgalarını bot içinde kullanıyorsanız, sistem saatinin kaymasını (drift) izleyin.

Timestamp doğrulama

• Emir gönderme ve yanıt alma loglarında zaman damgaları arasındaki tutarlılığı kontrol edin.
• Aynı olayın birden fazla kez işlenmesi gerekiyorsa (replay/dup), bunu zaman damgasıyla yönetmeyin; idempotency anahtarlarıyla yönetin.

6) “Düşük gecikme” için net uygulama mimarisi: tek süreç yerine akış ayrımı

VDS optimizasyonu kadar önemli olan şey botun iç mimarisidir. Tek bir event-loop içinde ağır işler yaparsanız gecikme artar.

Önerilen akış ayrımı

• Market data: WebSocket mesajlarını hızlı al, parse et, kuyruğa koy.
• Strategy: Kısa sürede karar üret, hesapları optimize et.
• Execution: Emirleri tek bir gönderim hattında yönet.
• Risk & durum: Emirlerin durumunu tut, rate-limit davranışını kontrol et.

Gereksiz yeniden denemeleri kesin

Trading entegrasyonlarında:

• Aynı emri tekrarlı göndermek latency ve maliyet üretir.
• Rate-limit hatalarında kör retry yapmayın.

Net hedef: retry stratejisi; backoff, jitter ve emir idempotency mantığıyla kontrol edilmiş olsun.

7) Ölçüm planı: 24 saatlik deneyle VDS seçimini somutlaştırın

Bu bölümün amacı “tahmin” yerine “kanıt” üretmek.

Deney tasarımı (uygulanabilir)

• Aynı bot koduyla iki farklı VDS lokasyonunu/konfigürasyonunu 12-24 saat çalıştırın.
• Her 5 dakikada bir:
• ortalama RTT/p95 RTT
• emir gönderme latency p95
• işleme süresi p95
• packet loss ve bağlantı sayıları
• swap/cpu/iowait durumlarını kaydedin

Karar eşiği

Şu sıralamayı uygulayın:

1. Emir gönderme latency p95 düşüyor mu?
2. Jitter azaldı mı?
3. Ağ kaybı (loss) sıfıra yakın mı?
4. Uygulama içi kuyruklar büyüyor mu?

Bu 4 maddeyi sağlayan VDS’i “düşük gecikme için doğru aday” olarak kabul edin.

Sonuç: VDS’de düşük gecikme için önce “ölç, kısalt, sabitle, doğrula”

Bot trading için VDS’de düşük gecikme; tek bir “hızlı sunucu” seçimiyle değil, ağ yolunu kısaltma (konum), bağlantı kurulumunu azaltma (DNS/TLS/keep-alive), işletim sistemi kaynaklarını sabitleme (RAM/swap/disk) ve zaman senkronunu doğrulama ile elde edilir. Aksiyon olarak bugün yapmanız gereken sıralama:

1) Botun gecikme bileşenlerini loglayın (alım → işleme → emir → yanıt). 2) İki farklı VDS lokasyonunda 12-24 saat ölçüm yapın; p95 ve jitter’i kıyaslayın. 3) REST/HTTP isteklerinde bağlantı yeniden kullanımını açın, DNS caching’i doğrulayın. 4) RAM/swap ve disk I/O’yu izleyin; swap devreye giriyorsa kapasiteyi düzeltin. 5) NTP zamanını doğrulayın ve timestamp tutarlılığını kontrol edin.

Bu adımları uygularsanız, gecikmeyi “tahmin” yerine sayılarla düşürdüğünüzü kanıtlayabilirsiniz.