Örnek sorular
Pf Apm Profiling Bottleneck CorrelationZorluk 1
Yük testi sırasında yük üretici aracının yanında bir APM (Application Performance Monitoring) aracı çalıştırmak neden faydalıdır?
- aAPM, sanal kullanıcıları kendisi simüle edebildiği için yük üreticisinin yerini tamamen alır; bazı APM ajanları sentetik trafik enjekte edebilir
- bAPM sadece test bittikten sonra, nihai PDF raporu üretmek için önemlidir
- cAPM, yük aracının gecikmeyi kaydettiği aynı anlarda sunucu tarafı sinyalleri (CPU, GC, DB havuzu, thread durumu) yakalar.✓
- dAPM sadece fonksiyonel testlerle ilgilidir, performans testleriyle ilgili değildir
Açıklama:APM araçları, yük aracının dışarıdan gecikme/throughput ölçtüğü aynı anlarda sistemin içinde (CPU, garbage collection, bağlantı havuzları) neler olduğuna görünürlük sağlar; bu, istemci tarafındaki bir belirtiyi sunucu tarafındaki bir nedenle eşleştirmeyi mümkün kılar.
Pf Apm Profiling Bottleneck CorrelationZorluk 1
Bir sistemin yük testi bağlamında "darboğaz" (bottleneck) nedir?
- aDoygunlaştığında sistemin genel throughput'unu sınırlayan belirli kaynak.✓
- bThroughput'u sınırlayıp sınırlamadığına bakılmaksızın, test sırasında CPU tüketen herhangi bir bileşen
- cScripting sırasında yazılması en uzun süren sanal kullanıcı script adımı
- dYük testi bitmeden önce çalıştırılan son istek
Açıklama:Darboğaz, doygunlaştığında throughput'u sınırlayan kısıtlayıcı kaynaktır (ör. DB bağlantı havuzu, CPU, tek thread'li bir bileşen); doygunluk noktasından sonra eklenen yük, daha fazla tamamlanan iş yerine çoğunlukla kuyruklama ve artan gecikmeye dönüşür.
Pf Apm Profiling Bottleneck CorrelationZorluk 1
Bir yük testinde, 500 eşzamanlı kullanıcıdan sonra istemci tarafında gözlenen p95 gecikmesi keskin biçimde artıyor. Sunucunun darboğaz olduğu sonucuna varmadan önce makul bir sonraki adım nedir?
- aGecikme arttığı için hemen sunucuyu darboğaz olarak raporlamak
- bTesti durdurmak, çünkü artan p95 gecikmesi her zaman test konfigürasyonunun (VU sayısı, ramp-up) yanlış olduğu ve yeniden yapılması gerektiği anlamına gelir
- cEmin olmak için sanal kullanıcı sayısını daha da artırmak
- dAynı zaman aralığında sunucu tarafı metriklerine (CPU, GC duraklamaları, DB havuzu bekleme, thread kuyruğu) bakmak.✓
Açıklama:Sadece istemci tarafında gözlenen gecikmenin artması darboğazın nerede olduğunu kanıtlamaz; sorun sunucuda, ağda ya da yük üreticinin kendisinde olabilir. Nedeni sunucuya bağlamadan önce aynı zaman penceresindeki sunucu tarafı metrikleriyle eşleştirmek gerekir.
Pf Apm Profiling Bottleneck CorrelationZorluk 1
Yük testi sırasında bir veritabanı bağlantı havuzu gibi bir kaynak için "doygunluk" (saturation) ne anlama gelir?
- aKaynağın işletim sistemi tarafından yeniden başlatılmış olması; bu da iç sayaçlarını ve bağlantı durumunu sıfırlar
- bKaynağın maksimum kapasiteye yakın kullanılması; bu yüzden yeni talebin beklemesi gerekmesi.✓
- cKaynağın yük testi tarafından kalıcı olarak devre dışı bırakılmış olması
- dKaynağın yanıt süresinin sıfıra düşmüş olması
Açıklama:Doygunluk, bir kaynağın (CPU, bağlantı havuzu, thread pool vb.) %100'e yakın kullanım oranında olması demektir; sonraki istekler bu kaynak için kuyrukta bekler, bu da genellikle yük aracının gözlemlediği gecikme artışına yol açan şeydir.
Pf Apm Profiling Bottleneck CorrelationZorluk 2
Bir darboğazın nerede olduğunu bulmaya çalışırken sadece istemci tarafı gecikmesine bakmak neden yanıltıcı olabilir?
- aSadece toplam gidiş-dönüş süresini gösterir, bu sürenin büyük kısmına hangi iç bileşenin neden olduğunu belirtmez.✓
- bİstemci tarafı gecikme rakamları yük test araçları tarafından her zaman uydurulur
- cİstemci tarafı gecikme, sunucu tarafı gecikmesinden farklı bir birimle ölçülür, bu da karşılaştırmayı imkânsız kılar
- dİstemci tarafı gecikme, sunucu yükünden bağımsız olarak asla değişmez
Açıklama:İstemci tarafında gözlenen gecikme uçtan uca bir ölçümdür; bir şeyin yavaş olduğunu söyler ama hangi iç adım/bileşenin sorumlu olduğunu söylemez; bu yüzden gerçek darboğazı izole etmek için iç (sunucu tarafı) metriklerle eşleştirilmesi gerekir.
Pf Apm Profiling Bottleneck CorrelationZorluk 2
Bir yük testinde, yük üreticinin kendi host'u %95 CPU kullanımı gösterirken hedef sunucu sadece %30 CPU kullanımı gösteriyor, ama istemci tarafında gözlenen gecikme yüksek. En olası açıklama nedir?
- aDarboğazın kesinlikle veritabanı olduğu
- bSunucu açıkça sağlıklı olduğu için sonuçların olduğu gibi güvenilmesi gerektiği; sağlıklı sunucu metrikleri her zaman istemci deneyiminin doğru olduğu anlamına gelir
- cYük üretici ile sunucu arasındaki ağın kesinlikle doygun olduğu
- dYük üreticinin kendisi darboğaz olabilir; bu yüzden gözlenen gecikme sunucunun gerçek davranışını yansıtmayabilir.✓
Açıklama:Yük üreticinin host'u CPU açısından doygunsa, istekleri zamanında gönderemeyebilir ya da yanıtları doğru zaman damgalayamayabilir; bu da sunucu sorunu gibi görünen ama aşırı yüklenmiş istemciden kaynaklanan yanıltıcı gecikme rakamları üretir. Bu, istemci tarafı darboğazının sunucuya yanlış atfedilmesinin klasik bir örneğidir.