Web Uygulamaları için Yük Testi Stratejileri: Kırılma Noktalarını Kullanıcılar Bulmadan Bulun

Performans sorunlarının %80'i testlerle değil, son kullanıcılar tarafından keşfedilir. Yük testi, kullanıcılar sorunlarla karşılaşmadan önce gerçek dünyadaki trafik modellerini uygulamanıza göre simüle ederek bu oranı tersine çevirir. Kara Cuma trafiğini yöneten bir site ile çöken bir site arasındaki fark, neredeyse her zaman birisinin önce yük testi yapıp yapmadığıdır.

Bu kılavuz, web uygulamaları, e-Ticaret platformları ve ERP sistemleri için yük testi metodolojisini, araç seçimini, test tasarımını ve sonuçların yorumlanmasını kapsar.

Önemli Çıkarımlar

• Yük testi yalnızca tek bir uç noktayı etkilemekle kalmayıp, gerçekçi kullanıcı davranışını simüle etmelidir
• Optimize etmeden önce performans temellerini belirleyin --- ölçmediğiniz şeyi iyileştiremezsiniz
• Üretim benzeri bir ortamda yük testlerini çalıştırın; Aşama sonuçları üretim davranışını yansıtmayabilir
• Dağıtımdan önce performans gerilemelerini yakalamak için CI/CD'deki yük testlerini otomatikleştirin

---

Yük Testi Türleri

---

k6 ile Yük Testi

Temel Yük Testi

// k6/load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp up to 50 users
    { duration: '5m', target: 50 },   // Stay at 50 users
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    http_reqs: ['rate>100'],
  },
};

export default function () {
  // Simulate realistic user behavior
  const homeResponse = http.get('https://example.com/');
  check(homeResponse, {
    'homepage status is 200': (r) => r.status === 200,
    'homepage loads in under 1s': (r) => r.timings.duration < 1000,
  });
  sleep(Math.random() * 3 + 1); // 1-4 seconds think time

  const productsResponse = http.get('https://example.com/api/v1/products');
  check(productsResponse, {
    'products API is 200': (r) => r.status === 200,
    'products API under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(Math.random() * 2 + 1);
}

e-Ticaret Kullanıcı Yolculuğu Testi

// k6/ecommerce-journey.js
import http from 'k6/http';
import { check, group, sleep } from 'k6';

export const options = {
  scenarios: {
    browsing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '10m', target: 200 },
        { duration: '5m', target: 0 },
      ],
      exec: 'browsingScenario',
    },
    purchasing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 20 },
        { duration: '10m', target: 20 },
        { duration: '5m', target: 0 },
      ],
      exec: 'purchaseScenario',
    },
  },
  thresholds: {
    'http_req_duration{scenario:browsing}': ['p(95)<800'],
    'http_req_duration{scenario:purchasing}': ['p(95)<2000'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browsingScenario() {
  group('Browse Products', () => {
    http.get('https://store.example.com/');
    sleep(2);
    http.get('https://store.example.com/products');
    sleep(3);
    http.get('https://store.example.com/products/sample-product');
    sleep(2);
  });
}

export function purchaseScenario() {
  group('Purchase Flow', () => {
    // Browse
    http.get('https://store.example.com/products/sample-product');
    sleep(1);

    // Add to cart
    http.post('https://store.example.com/api/cart', JSON.stringify({
      productId: 'prod_123',
      quantity: 1,
    }), { headers: { 'Content-Type': 'application/json' } });
    sleep(2);

    // Checkout
    http.get('https://store.example.com/cart');
    sleep(3);

    // Place order (simulated)
    const orderResponse = http.post('https://store.example.com/api/checkout/validate', JSON.stringify({
      email: `test-${__VU}@example.com`,
    }), { headers: { 'Content-Type': 'application/json' } });

    check(orderResponse, {
      'checkout validates': (r) => r.status === 200 || r.status === 201,
    });
    sleep(1);
  });
}

Stres Testi (Kırılma Noktasını Bulun)

// k6/stress-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 500 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 1000 },
    { duration: '5m', target: 1000 },
    { duration: '5m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

---

Sonuçları Yorumlama

Temel Metrikler

Yaygın Darboğaz Modelleri

CPU'ya bağlı darboğaz: Yanıt süresi yük ile doğrusal olarak artar. P95 ve P99 yavaş yavaş ayrışır.

• Düzeltme: Sıcak kod yollarını optimize edin, CPU kapasitesi ekleyin veya yatay olarak ölçeklendirin

Veritabanı darboğazı: Yanıt süresi belirli bir yük eşiğinde katlanarak artar. Bağlantı havuzunun tükenmesi.

• Düzeltme: Sorgu optimizasyonu, bağlantı havuzu oluşturma, kopyaları okuma (bkz. veritabanı ölçeklendirme kılavuzu)

Bellek darboğazı: Zamanla kademeli bozulma. GC duraklamaları gecikme artışlarına neden olur.

• Düzeltme: Belleği artırın, bellek sızıntılarını düzeltin, nesne tahsisini optimize edin

Ağ darboğazı: Yanıt süresi tüm uç noktalarda eşit şekilde artar. Bant genişliği doygunluğu.

• Düzeltme: Statik varlıklar için CDN, sıkıştırma, yük boyutlarının azaltılması

---

Performans Temelleri

Bir Temel Oluşturma

Optimize etmeden önce mevcut performansınızı belgeleyin:

# Run baseline test
k6 run --out json=baseline-results.json k6/load-test.js

# Compare after optimization
k6 run --out json=optimized-results.json k6/load-test.js

Performans Bütçesi

Her uç nokta için kabul edilebilir performansı tanımlayın:

---

CI/CD Entegrasyonu

Otomatik Performans Regresyon Testi

# .github/workflows/performance.yml
name: Performance Test
on:
  push:
    branches: [main]

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run k6 load test
        uses: grafana/k6-action@v0.3.1
        with:
          filename: k6/load-test.js
          flags: --out json=results.json
        env:
          K6_TARGET_URL: ${{ secrets.STAGING_URL }}

      - name: Check thresholds
        run: |
          if grep -q '"thresholds":{".*":"fail"' results.json; then
            echo "Performance thresholds exceeded!"
            exit 1
          fi

---

Yük Testi Kontrol Listesi

Test Etmeden Önce

• Ortam, üretimle eşleşir (örnek türleri, veritabanı boyutu)
• Test verileri temsilidir (gerçekçi ürün sayısı, kullanıcı sayısı)
• İzleme etkin (test sırasında sunucu ölçümlerini izleyin)
• Paydaşlar bilgilendirilir (yük testleri uyarıları tetikleyebilir)
• CDN ve önbelleğe alma, üretimdeki gibi yapılandırıldı

Test Sırasında

• Sunucu CPU'sunu, belleği, disk G/Ç'yi izleyin
• Veritabanı bağlantılarını ve sorgu gecikmesini izleyin
• Hata oranındaki artışları izleyin
• Kaynak tükenmesini kontrol edin (dosya tanımlayıcıları, bağlantılar)
• Performansın düştüğü yük seviyesine dikkat edin

Test Ettikten Sonra

• Temel sonuçları belgeleyin
• Darboğazları ve bunların yük eşiklerini belirleyin
• Performans iyileştirmeleri için destek bildirimleri oluşturun
• Performans bütçesiyle karşılaştırın
• Optimizasyonlardan sonra takip testini planlayın

---

Sıkça Sorulan Sorular

Test prodüksiyonunu mu yoksa hazırlamayı mı yüklememiz gerekiyor?

Mümkünse her ikisi de. Düzenli testler ve CI/CD entegrasyonu için hazırlama. Aşamalandırma genellikle veritabanı boyutu, önbellek sıcaklığı, CDN yapılandırması ve ağ topolojisi açısından farklılık gösterdiğinden periyodik doğrulama için üretim (trafiğin düşük olduğu saatlerde). Yalnızca bir ortamı test edebiliyorsanız, aşamalandırmayı test edin ancak bunu mümkün olduğunca üretime benzer hale getirin.

Yük testlerini ne sıklıkla yapmalıyız?

Her dağıtımda duman testleri (CI/CD'de otomatikleştirilmiştir). Haftalık olarak veya büyük sürümlerden önce tam yük testleri. Stres testleri üç ayda bir veya bilinen yüksek trafikli etkinliklerden (indirimler, lansmanlar) önce yapılır. Bellek sızıntılarını ve uzun vadeli bozulmayı tespit etmek için testleri üç ayda bir bekletin.

Bir ERP sistemini nasıl yük testi yaparız?

ERP yük testi, farklı görevleri gerçekleştiren eşzamanlı kullanıcıların simüle edilmesini gerektirir: fatura oluşturma, satın alma siparişleri oluşturma, raporları çalıştırma, verileri içe aktarma. En ağır operasyonlara (rapor oluşturma, veri içe aktarma) ve en eşzamanlı operasyonlara (yoğun saatlerde sipariş girişi) odaklanın. ECOSIRE, destek hizmetlerimizin bir parçası olarak Odoo performans testini sağlar.

İstekler arasındaki gerçekçi düşünme süresi nedir?

E-Ticaret taraması için: 2-5 saniye. Formun doldurulması için: 10-30 saniye. Ödeme için: 15-60 saniye. Admin/ERP kullanımı için: 5-15 saniye. Yük testlerinize her zaman rastgele düşünme süresi ekleyin; sabit aralıklar gerçekçi olmayan senkronize yük modelleri oluşturur.

---

Sırada Ne Var?

Yük testi, optimizasyon çalışmalarınıza yön veren darboğazları ortaya çıkarır. Veritabanı darboğazları için veritabanı ölçeklendirmesi, statik varlık teslimi için CDN optimizasyonu ve elastik kapasite için otomatik ölçeklendirme ile takip edin.

Performans testi ve optimizasyon için ECOSIRE ile iletişime geçin veya altyapı stratejisinin tamamı için DevOps kılavuzumuzu inceleyin.

---

ECOSIRE tarafından yayınlandı - işletmelerin baskı altında performans gösteren uygulamalar oluşturmasına yardımcı oluyor.