27.257 MCP bağlantısı ölçüldü: p90 oturum başlatma bekleme süresi 35,5 saniyeye ulaşıyor

Tek bir makine, 35 günlük log

Bir mühendis, Claude Code'un geride bıraktığı bağlantı loglarını Model Context Protocol (MCP) gecikmesiyle ilgili nadir ampirik veri kümelerinden birine dönüştürdü. 16 Eylül 2026'da yayımlanan bir dev.to yazısında Achiya Cohen, 13 Ağustos ile 16 Eylül 2026 arasını kapsayan 33.599 log dosyasını ayrıştırdığını anlatıyor; bu dosyalarda 38.876 bağlantı denemesi, 22 sunucuda 27.257 tamamlanmış bağlantı ve 2.888 oturum bulunuyordu.

Yöntem için hiçbir yeni ölçüm aracı gerekmedi. Claude Code, bir MCP sunucusuna bağlantı başladığında (30.000ms zaman aşımı bilgisiyle birlikte) bir satır, bağlantı kurulduğunda ise başka bir satır yazıyor. Aynı log dosyası içindeki bu iki satırı eşleştirmek gerçek bir bağlantı gecikmesi veriyor. Cohen, tek makineli kurulumun zaten meselenin kendisi olduğunu vurguluyor: sentetik bir benchmark yerine geliştiricinin gerçekte deneyimlediği dağılımı yakalıyor.

Bağlantı başına gecikme kuyruğa gelene kadar iyi görünüyor

Tek tek bakıldığında bağlantılar sağlıklı görünüyor: medyan 582ms, p75 1.650ms, p90 3.678ms, p95 6.428ms ve p99 14.049ms. Ancak bağlantıların %39'u bir saniyeden uzun sürdü ve p99, istemcinin 30 saniyelik zaman aşımının yarısına yaklaşıyor; Cohen'e göre bu da kuyruğu (tail) görmezden gelinmez kılıyor.

Sunucu kodu değil, OAuth yenilemeleri

En çarpıcı bulgu, yavaş bağlantıların genellikle sunucunun suçu olmaması. Verilerin, aynı bağlantı penceresi içinde bir OAuth token yenilemesinin gerçekleşip gerçekleşmediğine göre ayrıştırılması, medyanı 3.170ms ve p90'ı 9.619ms olan 748 yenileme yolu bağlantısıyla, medyanı 550ms ve p90'ı 3.400ms olan 26.509 yenilemesiz bağlantıyı ortaya koyuyor. Bu, aynı sunucular, ağ ve makine üzerinde 5,8 katlık bir fark. Bağlantıların yalnızca %2,7'si bir yenilemeye denk geliyor; ancak token süresinin dolması kullanıcının koltuğundan rastgele göründüğü için bu küçük dilim, sunucu uygulamalarının suçu sanılan düzensiz ve yeniden üretilemeyen yavaşlıkların önemli bir kısmını üretiyor.

stdio medyanda kazanıyor, HTTP kuyrukta kazanıyor

Taşıma katmanı seçimi de iyi ortalamalar ve kötü kuyruklar örüntüsünü tekrarlıyor. stdio bağlantılarının (7.363) medyanı 222ms ama p90'ı 4.693ms; HTTP bağlantılarının (19.894) medyanı 676ms ve p90'ı 3.395ms. Yerel stdio sunucuları ağ devreye girmediği için medyanda yaklaşık üç kat daha hızlı; ancak süreç başlatmanın öngörülemeyen bir üst sınırı var ve npm davranışı sık suçlu olarak gösteriliyor; buna karşılık halihazırda çalışan bir HTTP sunucusu çok daha tutarlı davranıyor.

35 saniyelik p90'ı fan-out üretiyor

Manşet sayıları oturum düzeyinde. Bu makinedeki oturumlar medyanda 8, en fazla 16 sunucuya bağlandı ve bunlar arasındaki toplam bağlanma süresi medyanda 5,9 saniye, p90'da 35,5 saniye ve p99'da 81,8 saniyeydi. Oturumların üçte biri (%33,7) yalnızca bağlanmakla 10 saniyeden fazla zaman harcadı. Medyanına göre en yavaş sunucu (2.261ms, p90 10.413ms), Cohen'in Temmuz'da mcp-optional adlı 56 satırlık bir script ile çoktan devre dışı bıraktığı bir sunucuydu; stdio sunucularının oturum başına bir Node süreci başlatması, 16GB'lık bir M4 makinesinde açık olan yaklaşık 13 oturumda toplam yaklaşık 1,4GB bellek tüketmişti.

%29,7'lik bağlanamama oranı

38.876 denemenin 11.556'sı (%29,7) kuruldu satırı hiç loglamadı. Cohen bunu bir başarısızlık üst sınırı olarak ele alıyor; çünkü log rotasyonu bir dosyayı el sıkışmanın ortasında kesebilir, ancak dağılım tekdüze değil: tek bir uzak bağlayıcı, eksik bağlantıların 7.422'sinden sorumlu; bu da bir entegrasyonun hatayı hiçbir yerde göstermeden tekrar tekrar başarısız olduğuna işaret ediyor.

Taklit edilmeye değer bir ölçüm tuzağı

İlk geçişte maksimum 119 saniye ve p99 14,5 saniye çıktı; istemcinin bildirilen 30 saniyelik zaman aşımı düşünüldüğünde bu rakamlar canlı bağlantıları temsil edemez. Bunlar, duvar saati saymaya devam ederken dizüstü bilgisayarın uykuya geçmesinin yapay sonuçlarıydı. Cohen tüm ölçümleri 30 saniyede sınırladı, 27.281 örneğin 24'ünü (%0,09) attı ve sınırsız rakamların daha çarpıcı ama yanlış olacağını belirtti.

Cohen'in önerileri

• Herhangi birini ayarlamadan önce sunucu sayısını hesaplayın; oturum başına medyan sekiz sunucu varken, vasat bir sunucuyu çıkarmak, iyi bir sunucuyu optimize etmekten daha fazla kazandırır.
• Ağır sunucuları isteğe bağlı yapın; mcp-optional'ın yaptığı tek şey bu: bunları varsayılan olarak config'den çıkarın ve gerektiğinde geri ekleyin.
• Yavaşlık tekdüze değil düzensiz olduğunda OAuth yenileme yolundan şüphelenin.
• Ağır entegrasyonlar için halihazırda çalışan bir HTTP sunucusunu tercih edin; daha iyi bir kuyruk uğruna daha kötü bir medyanı kabul edin.
• Yeni ölçüm araçları inşa etmeden önce istemcilerin halihazırda yazdığı logları madencilik yapın.

Neden önemli

MCP, kodlama ajanlarının harici yetenekleri bağlamasının varsayılan yolu hâline geliyor ve yapılandırılan her sunucu, kullanıcıların hiçbir zaman kalem kalem görmedikleri ama tekrar tekrar ödedikleri oturum başına bir başlatma vergisi ekliyor. Cohen'in verileri, sezgisel teşhisin —yani belirli bir sunucunun basitçe yavaş olduğunun— genellikle yanlış olduğunu öne sürüyor: acı, OAuth yenileme kuyruklarında, süreç başlatma varyansında ve sessiz bağlantı başarısızlıklarında yoğunlaşıyor ve bunların hepsi fan-out altında birikerek büyüyor. Yazı ayrıca bu tür dağılım verilerinin, Claude Code çalıştıran herhangi bir makinedeki cache dizinlerinde bedavaya durduğunu gösteriyor; bu da böylesi rakamların kıt olduğu bir anda bağımsız doğrulamayı ucuzluyor. Achiya Automation'da istemci altyapısına karşı ajan araçları çalıştıran Cohen, başkalarının da kendi yenileme-yenilememe ayrımlarını ve sunucu sayılarını yayımlamaya açıkça davet ediyor.