Örnek sorular
Pf Load Model DesignZorluk 1
Performans testi yük modellemesinde, açık (open) yük modeli ile kapalı (closed) yük modeli arasındaki temel fark nedir?
- aAçık model, executor yapılandırmasından bağımsız olarak her zaman kapalı modelden daha fazla sanal kullanıcı simüle eder
- bAçık modelde geliş önceki yanıttan bağımsızdır; kapalı modelde kullanıcı önce yanıtı bekler✓
- cAçık model sadece read-only endpoint'ler için, kapalı model sadece write endpoint'leri için kullanılabilir
- dAynı sanal kullanıcı sayısında kapalı model her zaman açık modelden daha yüksek throughput üretir
Açıklama:Açık modelde geliş (arrival) hızı kontrol edilen bağımsız değişkendir. Kapalı modelde sabit bir kullanıcı popülasyonunun her biri bir sonraki isteği göndermeden önce öncekinin yanıtını bekler, yani geliş hızı yanıt süresine bağlıdır.
Pf Load Model DesignZorluk 2
Sabit sayıda sanal kullanıcının (VU) istek → bekle → istek döngüsünü tekrarladığı bir yük testi neden kapalı sistem modeli olarak kabul edilir?
- aÇünkü hedef sistemden bağımsız olarak her zaman tek bir yük üreteci makinesinde çalışır
- bÇünkü VU sayısı üreteçteki CPU çekirdek sayısının katı olmak zorundadır
- cÇünkü sadece REST API'leri hedefleyebilir, veritabanı ya da mesaj kuyruğu hedefleyemez
- dHer VU bir sonraki isteğini ancak önceki yanıtı aldıktan sonra gönderir, bu da hızı sınırlar✓
Açıklama:Kapalı modelde istek hızı, bağımsız kontrol edilen bir girdi değil, VU sayısı ve yanıt süresinin bir sonucudur — kapalı olmasını tanımlayan da bu bağımlılıktır.
Pf Load Model DesignZorluk 2
Performans testinde 'coordinated omission' (koordineli ihmal) nedir?
- aYavaş yanıt yüzünden daha az istek gönderilip gerçek gecikmenin gizlendiği bir ölçüm artefaktı✓
- bİki yük üretecinin yanlışlıkla aynı test veri dosyasını kullandığı bir konfigürasyon hatası
- cThink time'ın yanlışlıkla tüm simüle edilen kullanıcılar için sıfırda bırakıldığı bir hata
- dYük üreteci ile hedef sunucunun saatlerinin düzgün senkronize olmadığı bir ağ sorunu
Açıklama:Coordinated omission, ölçüm aracının kendi istek temposunun sistemin yavaşlığıyla 'koordineli' hale gelmesinden (bloklanmasından) kaynaklanır; tam olarak en kötü gecikmeler eksik örneklenir.
Pf Load Model DesignZorluk 1
Bir yük testi script'inde 'think time' nedir?
- aYük üretecinin çalıştırmadan önce test script'ini derlemek için harcadığı süre
- bBir testin zaman aşımına uğramadan önce çalışmasına izin verilen maksimum süre
- cGerçek kullanıcının istekler arasındaki bekleyişini simüle eden bilinçli bir duraklama✓
- dTest aracının ilk sanal kullanıcıyı başlatmadan önce beklediği süre
Açıklama:Think time, istekleri arka arkaya ateşlemek yerine, gerçekçi insan temposunu taklit etmek için simüle edilen kullanıcı eylemleri arasına eklenir.
Pf Load Model DesignZorluk 2
Bir ekip, yük testini test başlangıcında 0'dan 5.000 sanal kullanıcıya anlık olarak sıçrayacak şekilde yapılandırıyor. Bu durumun yarattığı riski en doğrudan hangi yük modelleme uygulaması ele alır?
- aİstek başına assertion sayısını azaltmak
- bHedef yüke kademeli çıkan bir ramp-up uygulamak✓
- cClient kütüphanesinde HTTP/1.1'den HTTP/2'ye geçmek
- dThink time'ı her istek için sabit 10 saniyeye çıkarmak
Açıklama:Kademeli bir ramp-up, ani bir yük şokunu önler ve hiçbir baseline olmadan tam yüke çarpmak yerine sistemin (ve gözlemcilerin) yük arttıkça davranışın nasıl değiştiğini görmesini sağlar.
Pf Load Model DesignZorluk 2
Bir ekip, istek gelişlerini mükemmel derecede eşit, sabit aralıklı olmak yerine neden bir Poisson süreciyle modellemek isteyebilir?
- aPoisson, gerçek trafiğin rastgele ve patlamalı gelişini sabit aralıktan daha iyi modeller✓
- bÇünkü Poisson gelişlerinin tüm test boyunca sıfır hata garanti ettiği söylenir
- cÇünkü sabit aralıklı yerleştirme teknik olarak hiçbir yük test aracında desteklenmez
- dÇünkü Poisson modelleme sözde herhangi bir ramp-up fazına olan ihtiyacı ortadan kaldırır
Açıklama:Poisson tarzı rastgele aralıklama, yapay şekilde pürüzsüz/eşit aralıklı sentetik bir desene kıyasla bağımsız gerçek kullanıcıların nasıl geldiğini daha iyi yansıtır.