SQL Server performans testi: yük altında sorgu gecikmesi

Albiferro Yazılım ve Sistem Limited Şirketi · Yayın 1 Kasım 2026

Ayrıntılı dokümantasyon →

SQL Server'da bir sorgunun tek başına hızlı olması yük altında da hızlı kalacağını göstermez: eşzamanlı oturumlar kilitler, bellek ve bağlantılar için yarışır. Performans testi uygulamanın sorgularını veritabanına doğrudan, hedef eşzamanlılıkta çalıştırır ve p95, p99 ile hata oranını ölçer. Genel yöntem veritabanı yük testi rehberindedir; bu sayfa SQL Server'a özgü kısmı anlatır.

SQL Server bağlantısı

1. Bağlantılar → Bağlantı ekle'ye tıklayın, Tür olarak SQL Server seçin ve bir ad verin (ör. orders-db).
2. Sunucu, Port (boşsa 1433), Veritabanı / servis, Kullanıcı ve Parola'yı girin. Mümkünse yalnızca gerekli tablolarda SELECT yetkisi olan ayrı bir kullanıcı kullanın; parola şifreli saklanır, testte yalnızca bağlantının adı geçer.
3. En çok açık bağlantı (runner başına): varsayılan 50. Toplam bağlantı ≈ runner sayısı × bu değer; veritabanının bağlantı sınırını aşmayacak şekilde ayarlayın.
4. Kaydet, sonra Test et. Veritabanına yalnızca bir bastion üzerinden ulaşılıyorsa bağlantıya bir SSH tüneli ekleyin.

SQL Server için SQL adımı

Sorguyu Sorgu alanına sabit metin olarak yazın; değerleri @p1 yer tutucusuyla Parametreler'de verin. Parametreler {{__VU}}, {{$randInt 1 100000}}, çıkarılmış değişkenler ya da CSV veri dosyasından değerler içerebilir; sorgu metninin içine şablon yazılamaz, böylece SQL enjeksiyonu olmaz. Check sekmesinde örneğin Satır sayısı = 1 ekleyin, Dene ile tek iterasyonu çalıştırıp dönen satırları görün, sonra Kaydet.

{"id": "ms", "name": "SQL Server", "protocol": "sql", "connection": "mssql-db",
 "sql": {"query": "SELECT TOP 10 * FROM Orders WHERE CustomerId = @p1", "params": ["{{__VU}}"]}}

Bir okumanın süresi pool'dan bağlantı beklemeyi, sorguyu ve bütün satırların alınmasını kapsar. Satırlar JSON nesneleri dizisi olarak kontrollere ve değişken çıkarmaya gider ($[0].status gibi). Hatalar türüne göre ayrılır: zaman aşımı, bağlantı reddi, yetki, bulunamayan tablo, kısıt ihlali, sözdizimi ve salt okunur ihlali.

Veriyi korumak

Spitfire bir sorgunun okuma mı yazma mı olduğunu kendisi anlar ve okuma sayamadığı her şeyi yazma sayar. Yazmalar adımda açıkça onaylanmadan test kaydedilmez, onaylanmışsa test her başlatıldığında ayrıca onay ister ve onay denetim kaydına yazılır (güvenlik beyanı).

Bu veritabanında salt okunur transaction yoktur; okumaları yalnızca Spitfire'ın sorgu kontrolü korur ve SQL adımının formu bunu uyarı olarak gösterir. Bu yüzden bağlantıya yalnızca okuma yetkisi olan bir kullanıcı verin.

Hangi sorguları yüklemeli?

Hangi sorguların yükleneceğini Query Store söyler: sorguları çalışma sayıları ve süreleriyle tutar. En sık çalışan ve toplamda en çok süre alan birkaç sorgu, testin iskeletidir.

Sorguları elle yazmak yerine veritabanının kendi schema'sından önerilmesini de isteyebilirsiniz (kurulum yöneticileri; schema'dan query önerileri). SQL Server için gereken yetkiler: db_datareader, VIEW DEFINITION ve EXPLAIN için SHOWPLAN; isteğe bağlı VIEW SERVER STATE. Her öneri SHOWPLAN_XML ile kontrol edilir: yalnızca plan alınır, sorgu çalıştırılmaz; her önerinin bir satır sınırı (TOP) vardır.

Ardından yük modelini seçin: beklenen eşzamanlılıkta sabit bir yük, ya da sınırı bulmak için basamaklı bir kırılma noktası testi. Sonuçları ortalamayla değil p95 ve p99 ile okuyun.

Sık karşılaşılan hatalar

• Login failed for user …: kullanıcı adı ya da parola yanlış, ya da kullanıcının o veritabanına erişimi yok. Parolayı yeniden yazıp kaydedin; Veritabanı / servis alanını kontrol edin.
• Bir TLS hatası: sunucu şifreli bağlantı istiyor; Sürücü parametreleri'ne encrypt = true ekleyin.
• Bağlantı sınırı hataları: runner sayısı × En çok açık bağlantı (runner başına) veritabanının kabul ettiğinden fazla; değeri düşürün ya da sınırı yükseltin.

Sık sorulan sorular