Bot Trading İçin VDS: Düşük Gecikmeyi Net Sağlama Rehberi

Bot trading (özellikle emir gönderme ve veri çekme) senaryolarında gecikme sadece “hız” değil, kârlılığı etkileyen doğrudan bir parametredir. Piyasa verisi ile emirlerin ulaştığı zaman arasındaki fark, slippage ve fırsat kaçırmaya yol açar. Bu rehberde amaç; VDS üzerinde düşük gecikme (latency) elde etmek için yapılacak teknik seçimleri, ayarları ve ölçülebilir doğrulamayı net bir sıraya koymaktır. Okuyunca, hangi katmanda nerede gecikme yaşadığınızı bulup düzelteceğiniz bir kontrol planına sahip olacaksınız.

1) İlk hedef: Gecikmenin nereden geldiğini ayırın

Bot trading’de tek bir “hızlandırıcı” yoktur. Gecikme; ağ yolu, çözümleme (DNS), zaman senkronu, uygulama mimarisi ve işletim sistemi planlayıcısı gibi katmanlarda oluşur. Bu yüzden önce şu üç metriği ayırın:

RTT (Round Trip Time): İstemciden VDS’ye ve geri gidişin toplam süresi.
Uçtan uca işleme süresi: Verinin VDS’de işlenip emir üretilene kadar geçen süre (application latency).
Zaman senkronu hatası: Hedef zaman damgalarıyla sistem saati arasındaki sapma (clock drift).

Pratik ölçüm yöntemi

Aşağıdaki yaklaşım, “kurulum yaptım ama neden hızlı değil?” sorusunu hızla yanıtlar.

VDS’ye bağlandıktan sonra ping ve mtr ile paket kaybı ve rota değişimini gözlemleyin.
mtr -rwzbc 200 <hedef-ip>
Uygulama tarafında her mesaj için zaman damgası saklayın.
Alım zamanı (exchange timestamp veya gateway timestamp)
İşleme başlangıcı
Emir gönderme zamanı
Kabul/ACK alma zamanı

Bu kayıtlar olmadan tuning sadece tahmin olur. Net sonuç için önce ölçümün temelini kurun.

2) VDS konum seçimi: En düşük gecikme için en büyük kaldıraç

Düşük gecikmenin ilk belirleyicisi, VDS’nin fiziksel konumudur. Aynı sağlayıcı içinde bile region/zone farkı ciddi değişim yaratır.

Net kural: “Exchange’e yakınlık”

Emir göndereceğiniz borsanın veya broker/gateway’in bulunduğu veri merkezine yakın lokasyon seçin.
Mümkünse aynı şehir/metro alanında kurulum hedefleyin.
Alternatif route’lar varsa, route değişimi gecikmeyi dalgalandırır; bu yüzden mtr ile rota tutarlılığını kontrol edin.

Provider tarafı performans sinyali

Sağlayıcı seçerken sadece “hız” yazan reklam metinlerine değil; aşağıdaki teknik sinyallere bakın:

Aynı lokasyonda farklı instancetype/cluster seçenekleri varsa daha iyi ağ varyantı seçin.
IP’ler arası performans farkını ölçün. Bazı durumlarda tek bir IP bloğu daha stabil olur.

Net karar için: Aynı özellikte 2-3 VDS adayını aynı gün içinde test edin (en az 24 saat veri toplayın). Sonuçlara bakıp kalın.

3) Ağ katmanı tuning: MTU, TCP ayarları ve DNS’yi düzeltin

Gecikme sorunlarının önemli bir kısmı uygulamanın değil, ağ katmanının yanlış varsayımlarından gelir.

DNS çözümleme gecikmesi

Bot trading sırasında her istek öncesi DNS çözümleme gecikmesi oluşursa, mikro düzeyde bile kayıp yaşarsınız.

Uygulamanız DNS resolve’u her istekle yapıyorsa, uygulama katmanında DNS cache kullanın.
Sistem tarafında hızlı resolver seçin.
/etc/resolv.conf yerine NetworkManager/systemd-resolved üzerinden kontrol edin.

MTU uyumu (özellikle tünel/overlay varsa)

Yanlış MTU, paket parçalanmasına (fragmentation) yol açar. Bu hem RTT’yi uzatır hem de jitter artırır.

Aynı hedefe karşı PMTU keşfi yapın.
Özellikle VPN/overlay kullanıyorsanız (WireGuard/OpenVPN), MTU’yu tünel üzerinden uyarlayın.

TCP pencereleri ve keepalive

VDS üzerinde sistemin TCP davranışları uygulama gecikmesini etkiler.

Uzun süreli bağlantılarda keepalive açık olsun.
Nagle etkisini azaltmak için (uygulamaya bağlı) gönderim stratejinizi netleştirin.
Her şeyi otomatik “genel ayar” ile değiştirmek yerine, önce ölçün: bağlantı başına gecikme ve retransmission oranı.

4) Zaman senkronu: NTP değil, hedefe uygun saat disiplini

Bot trading’de timestamp tutarsızlığı, “emir doğru zamanda üretildi ama kayıtlar geç” gibi maliyetlere dönüşür.

Net hedef: drift’i düşük tutun

Sunucuda time sync’i (NTP) doğru servisle çalıştırın.
Bulunduğunuz sağlayıcının saat senkronu altyapısına göre NTP sunucularını seçin.
Günlük ölçüm yapın: chronyc tracking veya benzeri çıktılarla drift ve offset değerlerini izleyin.

Uygulama tarafı: zaman damgalarını aynı referansa bağlayın

Exchange gateway timestamp’i varsa onu saklayın.
Yerel saat ve UTC dönüşümlerini tutarlı yapın.
Sistem saatini “log için” değil, karar mekanizması için de kullanıyorsanız deterministik bir pipeline tasarlayın.

5) Kernel ve çalışma zamanı: Gecikme jitter’ını azaltın

Düşük gecikmenin yanında en kritik düşman jitter’dır. Aynı ortalama gecikmede bile jitter artarsa emir zamanlaması bozulur.

CPU planlayıcı davranışı

Bot uygulamanızı VDS üzerinde ayrı süreç/worker olarak ayırın.
Gereksiz arka plan servislerini kapatın (özellikle sık disk yazan işler).
CPU throttling yaşayan bir instancetype seçmediğinizden emin olun.

Daha stabil I/O için disk düzeni

Bot trading genelde küçük veriyle çalışır; yine de log ve cache yazımı gecikme yaratır.

Log yazımını tamponlayın (uygulama logu için uygun yöntem).
Gereksiz disk swap kullanmayın.
Sürekli büyüyen debug log’ları için log rotation uygulayın.

Network interrupt ve CPU izolasyonu (ileri seviye)

Çok düşük gecikme hedefleyenlerde IRQ pinning ve CPU isolation kullanılabilir. Bu, her kurulumda aynı kazancı vermez; ancak jitter sorunu yaşanıyorsa değerlendirilir.

Net uygulanabilir yol: - Önce sar, ss, ethtool -S gibi araçlarla retransmission ve CPU yükünü doğrulayın. - Sonra CPU izolasyonu/irq ayarlarına geçin. - Değişiklik sonrası 24 saat karşılaştırmalı test yapın.

6) Yazılım mimarisi: Blocking işi kaldırın, akışı sadeleştirin

VDS tuning tek başına yeterli değildir. Uygulamanız “network hızlı ama işleme yavaş” noktasında kalırsa gecikme yine yüksek olur.

Blocking yerine asenkron/stream odaklı model

Websocket/stream tabanlı veri alımında tek thread’de ağır parsing yapmayın.
Emir üretimi ile veri alma sürecini ayırın.
Kuyruk (queue) tasarımını kontrol edin: aşırı büyüyen kuyruk jitter yaratır.

Serileştirme ve GC etkisi (dil seçimi)

Java/Node gibi runtime’larda garbage collection kaynaklı duraklamalar olabilir.
Uygulama profil çıkarın: hangi fonksiyonlar gecikmeyi artırıyor?
Mümkünse düşük tahsisli veri akışı kullanın.

Bağlantı stratejisi: Her istekte yeni bağlantı açmayın

HTTP/REST isteklerini tek tek yapmak yerine uygun olduğu yerde kalıcı bağlantı kullanın.
Emir gönderiminde TLS handshake gibi masrafları azaltın (session reuse).

7) İstikrarlı ölçüm planı: “Tek test” değil “tekrarlı deneme”

Gecikme konusu günlük hayatta oynaktır. Tek bir test sonucuna göre karar vermeyin.

Net test senaryosu

Aynı bot davranışı ve aynı veri hacmiyle test edin.
En az 24 saat çalıştırın.
Şu ölçümleri saklayın:
Ortalama latency
p95 / p99 latency (kuyruk etkisi)
packet loss
retransmission sayısı
emir ack süresi dağılımı

Sonuçları kıyaslama ölçütü

VDS’i “hızlı” diye değil, şu hedeflerle kıyaslayın:

p99 latency düşüyor mu?
jitter dalgalanması azalıyor mu?
emir ack süresinde kuyruk kısalıyor mu?

8) Karşılaştırma: Gecikme için yapılacak işlerin öncelik sırası

Aşağıdaki tablo, zamanınızı en verimli harcamanız için “etki” ve “uygulama zorluğu”nu birlikte gösterir.

Öncelik	Yapılacak iş	Beklenen etki	Zorluk
1	VDS lokasyonunu borsa/gateway’e yakın seçmek	Çok yüksek	Orta
2	Zaman senkronu (drift/offset kontrolü)	Yüksek	Düşük
3	DNS cache + resolver kontrolü	Orta-yüksek	Düşük
4	Paket kaybı/rota analizi (mtr) ve ağ sorunlarını temizleme	Yüksek	Orta
5	Uygulama akışını asenkronlaştırma, queue kontrol	Yüksek	Orta
6	Log ve I/O kaynaklı gecikmeleri azaltma	Orta	Düşük-orta
7	MTU uyumu ve TCP davranışlarını hedefe göre düzenleme	Orta	Orta-ileri
8	CPU isolation/IRQ pinning (ileri seviye)	Değişken	İleri

9) Pratik kontrol listesi (kurulumdan sonra yapılacaklar)

Aşağıdaki listeyi kurulum bitince sırayla uygulayın. Her madde için bir “doğrulama” adımı ekledik.

Lokasyon testi: Aynı özellikte 2 aday VDS ile 24 saat karşılaştırma yap.
mtr ile rota tutarlılığı: Paket kaybı ve rota değişimi olmamalı.
Zaman senkronu: drift ve offset değerleri stabil olmalı.
DNS cache: Uygulama ilk resolve dışında per-istek çözüm yapmamalı.
Websocket/stream modeli: Veri alma ve emir üretimi ayrı akışlarda çalışmalı.
Log disiplini: Disk yazımı gecikme yaratmayacak şekilde sınırlandırılmalı.
p95/p99 kayıt: Ortalama tek başına yetmez; kuyruk etkisini ölç.
Değişiklik sonrası yeniden test: Her tuning sonrası en az birkaç saatlik doğrulama yap.

Sonuç: Düşük gecikmeyi “tuning listesi” ile değil, ölçümle yönetin

Bot trading için VDS üzerinde düşük gecikme, doğru lokasyon + doğru zaman senkronu + ölçülebilir ağ/uygulama optimizasyonu ile sistematik şekilde elde edilir. İlk adım olarak VDS lokasyon adaylarını karşılaştırın, ardından zaman senkronu ve DNS/bağlantı akışını sabitleyin. Sonra p95/p99 dağılımlarını izleyerek kernel ve CPU/IRQ gibi ileri ayarlara geçin.

Aksiyon önerisi: Bugün kurduğunuz ilk VDS üzerinde 24 saat log + p95/p99 latency toplayın; ardından sadece tek bir başlıkta (ör. DNS cache veya lokasyon) değişiklik yapıp farkı doğrulayın. Böylece gereksiz ayarlarla zaman kaybetmeden, gerçekten gecikmeyi düşüren hamleleri netleştirirsiniz.