Bot Trading için VDS: Düşük Gecikme Nasıl Sağlanır?

Bot trading (otomatik alım satım) sistemlerinde performansı belirleyen tek şey CPU gücü değildir. En kritik fark, emir gönderme ile emir gerçekleşmesi arasındaki gecikmenin (latency) düşürülmesi ve bu gecikmenin tutarlı kalmasıdır. Bu rehberde, VDS seçimi ve sunucu kurulumu üzerinden düşük gecikmeyi nasıl elde edeceğinizi; ölçüm, network yolunu sadeleştirme, kernel ayarları ve uygulama mimarisiyle birlikte adım adım açıklıyoruz. Ayrıca “hız mı pahalı mı?” sorusunu da somut ölçüm mantığıyla yanıtlayacağız.

1) Önce metriği sabitle: Latency nerede ölçülür?

Düşük gecikme hedefi koymak tek başına işe yaramaz; nereden nereye ölçtüğünüz netleşmezse yaptığınız ayarlar başarı getirmez. Botlarda genelde üç farklı katmanda gecikme görülür:

Uygulama içi gecikme: Order üretimi, JSON/CSV parse, kripto/decimal dönüşümleri, senkron beklemeler.
Ağ gecikmesi: VDS’den borsanın API endpoint’lerine giden yol (routing) ve retransmit’ler.
Sunucu işleme gecikmesi: Kernel scheduling, interrupt yükü, disk I/O kuyruğu (log yazma gibi).

Hedef ölçüm kurgusu

Aşağıdaki ölçüm hedeflerini aynı anda takip edin:

Emir isteği çıkış saati (bot uygulamasında)
API yanıtı alma saati (HTTP/websocket client’ta)
Emir “ack”/“filled” olay zamanları (borsa tarafında sağlanan event’lerden)
Sunucuda CPU yükü + network interface istatistikleri

Örnek olarak uygulama tarafında logları şu formatta zaman damgalarıyla tutun: event_type, t_send_ns, t_recv_ns. Bu sayede gecikmeyi tek bir sayı sanmazsınız.

2) VDS konumu: Gecikmenin en büyük kazancı veri merkezidir

Bot trading’de “en hızlı” VDS çoğu zaman en pahalı model değil; borsaya yakın olan ve ağ kalitesi daha istikrarlı olandır.

Veri merkezi seçerken net kriterler

Şunları kontrol edin:

Borsanın bulunduğu bölgeye yakınlık: Örneğin Avrupa borsaları için Avrupa lokasyonu hedefleyin.
İnce yol (route) sayısı: Aynı bölgede farklı sağlayıcılar farklı routing’ler kullanır. Bu fark ciddi latency yaratır.
Ağ sınıfı (network tier): Provider, düşük gecikme için “premium network” veya “high performance network” gibi tanımlamalar kullanır. Bunun SLA’sı ve pratik test sonucu birlikte değerlendirilir.
Çıkış (egress) kalitesi: Packet loss (kayıp) düşük değilse “ortalama” latency iyi görünse bile tail latency artar.

Pratik test: Basit ama kararlı

Sipariş bekletmeyi artıran darboğazı yakalamak için şu testi yapın:

Aynı saat aralığında birkaç kez ping ile değil, gerçek API endpoint ile test edin.
Websocket kullanıyorsanız: handshake + ilk mesaj alma süresini izleyin.
Ölçümlerde özellikle %95/%99 percentile değerlerine bakın. Ortalama, bot trading’de yanıltır.

3) Ağ katmanı ayarları: Paket kaybını sıfıra yaklaştırın

Düşük gecikmenin ön şartı, gecikmenin artmasına neden olan ağ olaylarını azaltmaktır.

İnterface ve routing sadeleştirme

Mümkünse VDS üzerinde gereksiz servisleri kapatın (log agent, ağır monitoring, sık aralıklı dış sorgular).
Sunucudan borsaya giden trafiği farklı ağ/overlay katmanlarına takmayın.
Eğer sağlayıcı birden fazla NIC/route sunuyorsa, tek birincil route’u standardize edin.

Queue ve retransmit etkisi

Packet loss varsa TCP retransmit’leri tail latency’yi yükseltir. Bu yüzden hedefiniz:

ethtool ile interface hızını ve duplex durumunu kontrol edin.
Sistem loglarında retransmit, reset, timeout sinyallerini tarayın.
DNS performansını sabitleyin (aşağıdaki başlıkta).

4) DNS ve endpoint stratejisi: “Bekleme”yi kaldırın

Botlarda gecikme sadece ağ yolu değil; isim çözümleme ve bağlantı kurma adımlarından da gelir.

DNS’i stabilize edin

Uygulama içinde her istek öncesi DNS çözümlemeyi tetikleyen tasarımlardan kaçının.
VDS üzerinde DNS resolver’ı düzenleyin; cache sürelerini rasyonel tutun.
Sabit borsaya bağlanıyorsanız, DNS TTL’lerini dikkate alarak bağlantı stratejisini planlayın.

Bağlantı kurulumu: Keep-Alive ve gerçek bağlantıyı ölçün

HTTP/1.1 veya HTTP/2 kullanıyorsanız:

Keep-Alive açık olsun.
Connection reuse mantığını test edin.

Websocket’te:

Tek bir websocket oturumu üzerinden emirleri/market verisini yönetin.
Heartbeat aralıklarının yanlış ayarlanması gereksiz yeniden bağlanmaya yol açar; bunu loglarla yakalayın.

5) Kernel ve zamanlama: CPU’yu “boşta bırakmak” latency’yi düşürür

VDS üzerinde kernel scheduling ayarları, özellikle düşük gecikme hedefinde belirleyicidir.

En kritik tuning adımları

Aşağıdaki başlıklar genel uygulama mantığı sunar; sağlayıcınızın sunduğu izinler ve kernel sürümü uygulanabilirliği etkiler:

CPU governor: Performans odaklı governor kullanın.
NTP/senkron saat: Zaman damgalarıyla çalışıyorsanız NTP (Network Time Protocol) doğru olmalı.
Interrupt yönetimi: Çok çekirdekte interrupt dağılımı performansı etkileyebilir. Düzgün dağıtım gecikme tutarlılığını artırır.
Swappiness ve memory davranışı: Swap’a düşmek latency’yi yükseltir. Swap’ı gereksiz kullanmayın.

Uygulama düzeyi: Thread/Process mimarisi

Bot trading servisiniz tek bir thread’de sık CPU işi yapıyorsa emir üretimi gecikir.
Ağ işlemi ile hesaplama işini ayırın (ör. I/O thread’i + worker process).
Logları senkron şekilde disk’e yazmak yerine bir tamponlama (buffering) stratejisi kullanın; aksi halde disk I/O kuyrukları gecikmeye sızar.

6) Disk ve yedekleme (backup): Yazma işini kontrol et

Düşük gecikme hedefinde disk, “uçtan uca” etkiler yaratabilir. Bot trading’de sık log yazımı ve gereksiz veri tutma gecikmeyi artırır.

Log stratejisi

Yüksek frekansta JSON log basmayın.
Logları yerel tamponlayın; gerektiğinde belirli aralıklarla flush edin.
En azından latency analizi için zorunlu alanları saklayın; tüm ham veriyi sınırsız tutmayın.

Yedekleme (backup) zamanlaması

Backup işlerini yoğun saatlerde çalıştırmayın.
Yedekleme sürecinin CPU ve disk I/O tüketimini sınırlayın.
Mümkünse yedekleme trafiğini borsaya giden trafiği etkilemeyecek şekilde planlayın.

7) Ölçüm ve karşılaştırma: Aynı hedef, farklı VDS

En iyi VDS, “mutlak en düşük fiyat” değil; sizin borsanıza ve uygulama trafiğinize göre ölçümle kanıtlanan sonuçtur. Aşağıdaki tablo, düşük gecikme odaklı değerlendirmede pratik bir kontrol seti sunar.

Kriter	Neden önemli	Kabul edilebilir hedef	Nasıl ölçülür
50/95/99 percentile latency	Ortalama aldatır	Ortalama kadar tail da düşük olmalı	Uygulama logları + borsa event’leri
Packet loss	Retransmit = tail latency	Pratikte çok düşük	Interface istatistikleri + endpoint test
DNS/bağlantı kurma süresi	İlk istek geciktirir	İstikrarlı (tail kontrol)	Connection kurulum logları
CPU yükü ve scheduling	Queue artışı yapar	Yük dalgalanmaması	`top/htop`, process bazlı ölçüm
Disk I/O ve flush sıklığı	Log gecikmeye sızabilir	Sürekli yüksek I/O yok	Disk I/O istatistikleri
Websocket sürekliliği	Yeniden bağlanma maliyetlidir	Bağlantı kopmaları minimal	Websocket log + reconnect sayısı

8) Tipik hatalar ve net düzeltmeler

Hata 1: Sadece ping’e bakmak

Ping, TCP/HTTP/websocket gerçek davranışını temsil etmez. Çözüm: Borsa endpoint’ine karşı gerçek istek (veya websocket handshake) ölçün.

Hata 2: Her istek için yeni bağlantı açmak

Çözüm: HTTP keep-alive / connection reuse kullanın. Websocket’te tek oturum stratejisini koruyun.

Hata 3: Yoğun loglama

Çözüm: Log seviyesini düşürün, tamponlayın, gereksiz alanları azaltın.

Hata 4: DNS çözümleme gecikmesi

Çözüm: Uygulama tasarımında DNS tekrarını azaltın; resolver’ı düzgün yapılandırın.

Hata 5: Kernel/CPU tuning yapmadan “daha güçlü CPU” aramak

Çözüm: Önce tail latency nedenini bulun; scheduling, interrupt dağılımı ve swap/sıralama etkilerini kontrol edin.

9) VDS seçiminde somut “checklist”

Karar vermeyi hızlandırmak için seçim sürecini şu adımlarla netleştirin:

Lokasyon: Borsanın bölgesine yakın veri merkezi seçin.
Ölçüm planı: İlk günden 50/95/99 percentile latency loglayın.
Ağ istikrarı: Packet loss/tail davranışını görün.
Kaynak tahsisi: Overselling riski olmayan, tutarlı performans sunan yapı tercih edin.
SSD/NVMe: Disk gecikmesi için “performans” sınıfı disk kullanımı hedefleyin.
Kontrol paneli ve servis yükü: Trading botuna müdahale etmeyen, gereksiz arka plan servisleri olmayan bir kurgu yapın.
Güvenlik ve erişim: Botun SSH kullanımı minimum olsun; sadece gerekli portlar açın.
Yedekleme: Backup işlerini tail latency dönemlerinden ayırın.

Sonuç: Aksiyon planı ile 1 haftada somut fark görün

Düşük gecikme hedefinde en doğru yaklaşım, rastgele VDS yükseltmek değil; önce ölçüm noktalarını sabitleyip ardından veri merkezi, ağ istikrarı, DNS/bağlantı kurulumu ve kernel/applikasyon davranışını birlikte optimize etmektir. Bu rehberdeki sırayı izleyin: (1) endpoint tabanlı latency ölçümü kurun, (2) lokasyon ve routing kaynaklı farkı test edin, (3) bağlantı ve DNS stabilitesini sağlayın, (4) disk/log ve kernel scheduling etkilerini kontrol edin, (5) tail latency’yi hedef alın. Son adım olarak, iki farklı VDS lokasyonu/sağlayıcıyı aynı bot senaryosunda karşılaştırıp 50/95/99 percentile sonuçlara göre seçiminizi kesinleştirin.