Uygulamanız on kullanıcıyla mükemmel şekilde çalışır. On bin satış gününde ne olur? Yük testi ve stres testi bunu yanıtlamanın iki farklı yolunu açıklar ve bunların karıştırılması, yaptıklarını düşündüğünüz şeyi kanıtlamayan testlere yol açar.

Bu kılavuzda her birinin neyi gösterdiği, ilgili test türleri ve sonuçların nasıl okunacağı açıklanmaktadır. Aşağıdaki küçük yüzdelik hesaplamayı Python 3.13’te simüle edilmiş sayılarla gerçekleştirdik. K6 komut dosyaları bizim yürütmediğimiz açıklayıcı örneklerdir ve kullanıcı sayıları ve hedefleri icat edilmiştir, bu nedenle bunları kendinizinkiyle değiştirin. Yoğun trafik bir saldırı gibi görünebileceğinden ve gerçek kesintilere neden olabileceğinden, bu testleri yalnızca sahip olduğunuz veya test etme izniniz olan sistemlerde çalıştırın.

Kısa cevap

Yük testi şu soruyu sorar: Beklediğimiz trafiği idare edebilir ve bunu yaparken hedeflerimize ulaşabilir miyiz? Bir stres testi şu soruyu sorar: Başarısız olmadan önce ne kadar alabiliriz, nasıl başarısız oluruz ve ne kadar çabuk toparlanırız?

Bir köprü düşünün. Bir yük testi, beklenen sayıda kamyonu karşıya geçirir ve bunun iyi olduğunu doğrular. Stres testi, sınırını ve önce uyarı verip vermediğini öğrenmek için ağırlık eklemeye devam eder. Neyse ki yazılımı kırmak köprüden daha ucuzdur.

Yük testi ve stres testi yan yana

Yük testi nedir?

Yük testi, beklediğiniz gerçekçi trafiği simüle eder ve sistemin nasıl davrandığını ölçer. Test edilecek bir hedefe ihtiyacı var, örneğin: “eşzamanlı 500 kullanıcıda, ödeme isteklerinin %95’i 800 ms içinde tamamlanıyor ve %1’den az hatayla.”

İşte bunun bir k6 betiği gibi görünebileceği. k6 testleri JavaScript’te yazılmıştır ve thresholds hedeflerinizi başarılı veya başarısız sonucuna dönüştürür:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep önemlidir. Düşünme süresi olmadan, her sanal kullanıcı sürekli olarak sunucuya saldırır ve aynı sayıda gerçek insanın üretebileceğinden çok daha fazla trafik üretir.

Stres testi nedir?

Stres testi kasıtlı olarak beklenen seviyelerin üzerine çıkar. Geçmeye çalışmıyorsun. Aşağıdaki gibi soruların yanıtlarını istiyorsunuz:

• Performans hangi seviyede düşmeye başlar?
• İlk önce hangi bileşen arızalanır: veritabanı mı, uygulama sunucuları mı yoksa üçüncü taraf çağrısı mı?
• Açık hatalarla zarif bir şekilde başarısız mı oluyor yoksa çöküp veri mi kaybediyor?
• Trafik düştüğünde kendiliğinden düzeliyor mu?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Bu son iyileşme aşaması sıklıkla unutulur ve belki de en değerli aşamadır. Arızayı iyi bir şekilde ele alan ancak manuel yeniden başlatma olmadan asla düzelmeyen bir sistem, yine de birisinin gece yarısı tamir etmesi gereken bir kesinti anlamına gelir. İdeal olarak, aşırı yük altında bir sistemin işi kontrollü bir şekilde kesmesi ve zaman aşımı yerine net 503 yanıt döndürmesi gerekir.

Başak, ıslatma ve diğer türler

Yük ve stres testleri daha geniş bir performans testi ailesine aittir:

Islatma testleri, kısa testlerin asla göremediği sorunları yakalar. Küçük bir bellek sızıntısı yirmi dakika boyunca zararsız görünebilir ve hizmeti yalnızca iki gün sonra çökertebilir. Spike testleri, trafiğin kademeli olarak artmadığı flaş satışlar gibi etkinliklere uygundur.

Önemli olan metrikler

Ortalamalar neden yanıltıcıdır?

Ortalamalar, gerçek insanların şikayet ettiği yavaş istekleri gizler. Bunu göstermek için, 95’i hızlı (80 ila 200 ms) ve 5’i çok yavaş (2,5 ila 4 saniye) olmak üzere 100 simüle edilmiş yanıt süresi oluşturduk ve ardından ortak istatistikleri hesapladık:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Şu rakamlara yakından bakın. Ortalama 302 ms hiç kimseyi tanımlamıyor. Tipik istekler yaklaşık 150 ms sürerken, yavaş istekler 3 saniyeden fazla sürdü. P95 bile 199 ms’de sağlıklı görünüyor ve yalnızca p99 sorunu ortaya koyuyor. P95 gibi bir rakam, isteklerin %95’inin bu kadar hızlı veya daha hızlı olduğu anlamına gelir.

Taleplerin yüzde biri de nadir görülen bir olay değil. Bir sayfa 50 istekte bulunursa, yavaş bir p99, sayfa görüntülemelerinin büyük bir kısmını etkiler. Sizin için önemli olan yüzdelik dilimlere yönelik hedefler belirleyin ve birkaçına birlikte bakın.

Araçlar

Bunlardan herhangi biri hem yük hem de stres testlerini çalıştırabilir. Bir özellik listesinin peşinde koşmak yerine, takımınızın becerilerine uygun olanı seçin. İşlem hattınızda bir tane kullanmak için CI/CD nedir konusuna bakın.

Bir test nasıl planlanır?

1. Hedefler belirleyin. En yoğun trafiğinizi bulmak ve hedefleri tanımlamak için gerçek analizleri kullanın.
2. Yolculukları seçin. Göz atma, arama ve ödeme yapma gibi gerçekçi kullanıcı davranışlarını gerçekçi oranlarda modelleyin. Yalnızca ana sayfaya tıklamak pek bir şey ifade etmez.
3. Gerçekçi bir ortam kullanın. Küçük bir hazırlama sunucusu üretimi tahmin edemez. Farklılıkları not edin.
4. Verileri hazırlayın. Gerçekçi hacimler kullanın, çünkü 100 satırda hızlı olan bir sorgu 10 milyon satırda taranabilir.
5. İnsanları uyarın. Operasyon ekibinize ve üçüncü taraflara bildirin ve ödeme sağlayıcısına kazara yükleme testi yapmayın. Uygun olduğu yerde harici hizmetleri taklit edin.
6. Küçük başlayın. Senaryonuzun çalıştığını doğrulamak için önce küçük bir duman testi yapın.
7. Her şeyi izleyin. Sunucu metrikleri olmadan, yavaşladığını göreceksiniz, ancak nedenini göremezsiniz.
8. Tekrarlayın. Her düzeltmeden sonra tekrar çalıştırın ve karşılaştırma yapmak için bir temel tutun.

Sonuçların okunması

Veritabanları yaygın bir darboğazdır; dolayısıyla sorun sorgular ise SQL sorgu optimizasyonu kılavuzumuzu okuyun. Tablonun son satırı önemli bir tuzaktır: Yükü oluşturan makinenin sağlığını da her zaman kontrol edin.

Yaygın hatalar

• İsteklerle kullanıcıların kafasını karıştırmak. Hedefin eş zamanlı kullanıcılar mı yoksa saniye başına istekler mi anlamına geldiğini açık bir şekilde belirtin.
• Düşünme süresini dışarıda bırakmak. Bu, trafiği şişirir ve yanıltıcı sonuçlar verir.
• Test çok geç. Lansmandan bir hafta önce, mimari sorunları düzeltmek için zaman kalmıyor.
• Tek bir uç nokta kullanma. Gerçek trafik; okuma, yazma ve aramaları birleştirir.
• Önbelleğe alma her şeyi gizler. Tekrarlanan aynı istekler yalnızca önbelleğinizi test edebilir, bu nedenle veriler değişiklik gösterebilir.
• Bir kez test ediliyor. Performans her sürümde değiştiğinden testleri düzenli olarak gerçekleştirin.

Son sözler

Beklediğiniz trafiği idare edebildiğinizi doğrulamak için yük testleri yapın ve bunu başaramadığınızda ne olacağını öğrenmek için stres testleri yapın. Küçük başlayın: En önemli kullanıcı yolculuğunuzu seçin, net bir hedef belirleyin ve izleme açıkken aşamalandırmaya karşı kısa bir test yapın. Bu ilk çalıştırma genellikle size bir şeyler öğretir ve oradan inşa edebilirsiniz.

Sık sorulan sorular

Öğrenmeye devam et