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

Bot trading (borsa botları) tarafında “hız” yalnızca sunucunun işlem gücüyle ilgili değildir. Emir gönderme, veri alma, sıralama mantığı ve log/İO işlemleri toplam gecikmeyi belirler. Bu rehberde VDS ile düşük gecikme hedeflerken hangi adımların gerçekten etkili olduğunu; ölçüm, mimari ve işletim sistemi ayarları üzerinden net şekilde göreceksiniz.

Hedefiniz; hem RTT/latency (round-trip time) değerlerini düşürmek hem de gecikme dalgalanmasını (jitter) kontrol altında tutmaktır. Yazının sonunda, kendi kurulumunuza uygulayabileceğiniz kontrol listesine ve doğru metriklerle doğrulama yöntemine sahip olacaksınız.

1) Önce coğrafya ve rota: “en hızlı” VDS konumu

Düşük gecikmenin ilk kaynağı, botunuz ile borsa/market veri sağlayıcısı arasındaki fiziksel mesafe değil; veri yolunun (routing) kalitesi ve hat kararlılığıdır.

Uygulayacağınız net seçim kriterleri

Aşağıdaki maddeleri bir “sıralama” mantığıyla değerlendirin:

Borsa sunucusuna en yakın bölgeyi hedefleyin. Cloud sağlayıcıların bölge seçeneklerinde (region/zone) ilgili ülke/şehir eşleşmesini tercih edin.
Aynı sağlayıcıda farklı bölge/cluster varsa, test ederek en düşük RTT’yi veren bölgeyi seçin.
Şehriniz Türkiye içinde olsa bile, borsa tarafı Avrupa veya başka bir merkezdeyse “Türkiye içi” seçim tek başına yeterli değildir.
Trafik yoğunluğunu azaltmak için tek bir bağlantı türüne (örn. tek uplink) sabit kalan mimari tercih edin. Bazı altyapılar paket kaybı ve jitter açısından dalgalı olabilir.

Test metrikleri: sadece ping değil

Ping ile kabaca ölçüm yapılır; fakat bot trading’de asıl kritik olan:

p50/p95 latency (tipik ve yüksek kuyruk gecikmesi)
packet loss (paket kaybı)
jitter (gecikmenin zaman içinde oynama miktarı)

Test yaklaşımı: - Botun kullandığı uç noktaya ping atın. - Ardından aynı hedefe karşı kısa aralıklı ölçüm yapın (ör. 1–2 dakikalık örneklem). 30–60 saniyelik ölçümle karar vermeyin.

2) VDS kapasitesi değil “tahmin edilebilir gecikme”

Bot trading’de gecikme, CPU’nun ortalama performansından çok “o an ne olacağı” ile ilgilidir. Bu nedenle VDS seçiminde odaklanmanız gerekenler:

CPU scheduling determinism: paylaşımlı oversubscription etkisini azaltan seçenekleri tercih edin.
Tek tenant (sizi yalnız kullandıran) izolasyon: VDS/VPS senaryolarında bile, iyi bir platformda daha tutarlı davranış görülür.
Disk I/O performansı: log yazma, statik dosya okuma, kısa aralıklı kayıtlar gecikmeyi artırabilir.

Net öneri: CPU + RAM + storage profilini eşleştirin

Genel kural: “en ucuz” değil, “en stabil” profili hedefleyin.

Yüksek sayıda eşzamanlı iş yapan botlarda CPU rezervi bırakın.
Zaman damgalı log (time-series) tutuyorsanız, yazma işlemlerini gecikmeye yol açmayacak şekilde yönetmek gerekir (aşağıda sistem ayarlarında geçecek).
Eğer bot mesajları çok hızlı işliyorsa, aynı anda veritabanı yoğun sorgu çalıştırmayın. Ayrıştırın: trading işini mümkün olduğunca ayrı süreç/katmanda tutun.

3) OS ve kernel ayarları: jitter kontrolü

Düşük gecikmede en büyük kazanımlardan biri, işletim sistemi tarafında “gecikme dalgalanmasını” azaltmaktır.

Neden kernel tuning önemli?

Zamanlayıcı (scheduler) ve ağ yığını ayarları paketlerin işlenme süresini etkiler.
Gereksiz servisler CPU’yu meşgul ederek gecikme kuyruklarını artırabilir.
Enerji tasarruf modları (bazı sistemlerde) işlemci frekansını oynatır ve jitter üretir.

Uygulanabilir pratik adımlar

Aşağıdaki ayarlar dağıtıma göre değişir; fakat yaklaşım ortaktır:

Sistem performansı (stabilite)

Kullanmadığınız servisleri kapatın.
Otomatik güncelleme/reboot planlarını çalışma saatleri dışında yapın.
Zaman ayarlama: NTP ile saat senkronunu kurun.

Ağ yığını

TCP offload gibi özellikler bazı senaryolarda fayda sağlar, bazılarında ölçüme göre zararlı olabilir. Bu yüzden “tek seferde varsayılan her şeyi değiştirme” yerine, ölçerek ilerleyin.
Ağ paket kuyruğu ve yeniden iletim davranışını etkileyen parametreleri, üretim öncesi test ortamında doğrulayın.

Hızlı doğrulama yöntemi

Kernel ayarını yaptıktan sonra sadece “ping düştü” diye sevinmeyin. Botun: - Emir gönderme → yanıt alma süresi - Veri mesajı → işleme tamamlanma süresi - Kuyrukta bekleme süreleri gibi kendi uygulama metriklerini loglayın.

4) Ağ mimarisi: uygulama katmanında gecikme küçültme

VDS içinde yaptığınız uygulama tasarımı, gecikmeyi doğrudan etkiler. Çünkü network gecikmesi tek başına toplam gecikmenin tamamı değildir.

Net mimari prensipleri

Tek thread/async modelinde tutarlı bir akış kullanın. Çok fazla senkron bloklama (blocking I/O) gecikme kuyruklarını büyütür.
Mesaj işleme sırasında:
Her mesajda dosya yazma yapmayın.
Senkron veritabanı sorgusu ile trading akışını kilitlemeyin.
JSON/seri hale getirme maliyeti yüksekse, mesaj formatını ve parse stratejisini optimize edin.

Sıfırdan uygulanacak örnek yaklaşım (yüksek seviye)

Trading engine: sadece gelen mesajı al, doğrula, strateji uygula, emir üret.
Log/telemetri worker: ayrı süreç.
Depolama/DB: ayrı worker ya da ayrı sunucu.

Bu ayrım, trading motorunun gecikme kuyruklarından etkilenmemesini sağlar.

5) Kaynak izolasyonu ve sistem süreçleri: “kim CPU’yu çalıyor?”

Gecikmenin en büyük düşmanı belirsiz CPU kullanımıdır.

Kontrol listesi

Aşağıdaki sorulara net cevap verin:

Trading süreci için CPU’nun tamamı rezerve mi, yoksa başka süreçler aynı anda mı çalışıyor?
Günlük log/rotasyon (logrotate), antivirus, yedek (backup) gibi işlerde saat eşleşmesi var mı?
Python/Node gibi runtime’lar için GC (garbage collection) tetiklenmeleri uygulama gecikmesine yansıyor mu?

Pratik izolasyon

Trading process’ini ayrı bir kullanıcı ile çalıştırın.
Gereksiz cron job’ları devre dışı bırakın.
CPU/Memory kullanımını sürekli izleyin (sadece yük artınca değil, stabil halde de).

6) Ölçüm planı: gerçek düşük gecikme kanıtı

Düşük gecikmeyi “hissederek” değil, metriklerle doğrulayın. Aksi halde yaptığınız değişikliklerin etkisini ayırt edemezsiniz.

Uygulama metrikleri (önerilenler)

Bot tarafında şu zamanları ayırın:

t_send: emir gönderme anı
t_ack: ack/yanıt alma anı
t_process_done: mesaj işleme bitişi

Bunlardan türetin: - ack latency = t_ack - t_send - processing latency = t_process_done - t_ack (veya mesaj alımı bazlı) - p50 ve p95 değerleri - Max değerler: en kötü anlar stratejinizi bozabilir

Sistem metrikleri

CPU idle yüzdesi (yüksek idle tutarlı mı?)
Disk yazma gecikmesi (özellikle log worker yoğunken)
Network packet loss

Önce test, sonra değişiklik

Bir değişiklik yapın → 30–60 dakika veri toplayın → önce/sonra karşılaştırın. Aynı gün içinde çok sayıda parametreyi aynı anda değiştirmeyin.

7) Sonuç: Düşük gecikme için 10 maddelik net aksiyon planı

Aşağıdaki listeyi uygulayın. Her madde, bot trading’de gecikme ve jitter üzerinde doğrudan etki yaratır:

Borsa/market veri sağlayıcısına en yakın VDS bölgesini test ederek seçin.
Ping ile değil, p50/p95 latency ve packet loss ile değerlendirin.
Trading işini log/DB depolamadan ayırın (worker mimarisi).
Gereksiz servisleri kapatın, otomatik reboot ve güncellemeleri çalışma dışına alın.
NTP ile zaman senkronunu kurun.
Kernel ve ağ yığın ayarlarını ölçerek yapın; tek seferde her şeyi değiştirmeyin.
Logları senkron yazma yerine kuyruk (queue) veya worker üzerinden yürütün.
CPU yoğun süreçleri trading sürecinden uzaklaştırın.
p50/p95/maximum metriklerini bot içinde loglayın ve kıyaslayın.
Her değişiklikten sonra 30–60 dakika ölçüm alıp önce-sonra raporu çıkarın.

İlk adım olarak, mevcut kurulumunuzda yalnızca botun ack latency ve processing latency metriklerini toplayın. Ardından VDS bölgesini ve çalışma saatindeki CPU/disk/network dalgalanmalarını hedefleyin. Bu iki kaynağı net şekilde kontrol ettiğinizde, bot trading tarafında gecikme hedefi belirgin biçimde daha ulaşılabilir hale gelir.