Performans Testi, bir uygulamanın yalnızca yoğun kullanıcı trafiği altında çöküp çökmediğini görmekten çok daha kapsamlı bir test ve ölçüm sürecidir. Temel amaç, uygulamanın belirli çalışma koşulları altında nasıl davrandığını doğru şekilde ölçmek, elde edilen metrikleri analiz etmek ve sonuçları anlamlı biçimde raporlamaktır. Bu nedenle performans testine başlamadan önce neyin test edileceğinin, hangi senaryoların çalıştırılacağının, test verilerinin nasıl oluşturulacağının, test ortamının nasıl yapılandırılacağının ve yükün nereden ve nasıl üretileceğinin belirlenmesi gerekir. Performans testi yalnızca web uygulamalarına yönelik değildir; API'ler, veritabanları, dosya işleyen uygulamalar, masaüstü uygulamaları ve farklı sistemlerle çalışan entegrasyonlar da performans açısından değerlendirilebilir. Test sürecinin en önemli noktalarından biri doğru bir referans oluşturmaktır. Öncelikle sistemin normal koşullardaki davranışı ölçülmeli, ardından yük kontrollü şekilde artırılarak Response Time, CPU, RAM, Database Bağlantıları, Connection Pool ve diğer ilgili metriklerde meydana gelen değişimler gözlemlenmelidir. Ancak doğru bir performans sonucu elde etmek için yalnızca sanal kullanıcı sayısını artırmak yeterli değildir. Gerçekçi test verisi kullanılmalı, test ortamı mümkün olduğunca production ortamına yakın ve temiz olmalı, uygulamanın mimarisi ve çalışma şekli anlaşılmalıdır. Bunun yanında yalnızca başarılı işlemlerden oluşan Happy Path senaryolarına bağlı kalınmamalı; timeout, dış entegrasyonların cevap vermemesi, servis hataları, cache'in temizlenmesi ve retry davranışları gibi negatif senaryolar da test edilmelidir. Özellikle mikroservis mimarilerinde kontrolsüz retry mekanizmaları zincirleme bir retry storm oluşturarak sistemi daha büyük bir performans problemine sürükleyebilir. Kısacası iyi bir performans testi, yalnızca sistemin ne kadar yük taşıdığını değil, hangi koşullarda, ne ölçüde ve neden performans kaybettiğini ortaya koymalıdır. Bu ölçümler, darboğazların belirlenmesini, kapasitenin anlaşılmasını ve sistemin gerçek kullanım koşullarındaki davranışının daha doğru değerlendirilmesini sağlar. Böylece test sonuçları teknik kararlar için somut bir temel oluşturur.
1) Performans Testi Sadece Yük Testi Değildir
Performans testini doğrudan “Load Test” ile eşitlemek en yaygın yanlışlardan biridir. Bir uygulamanın normal koşullardaki response time değerini ölçmek de performans testidir. Burada henüz sisteme ekstra yük vermeden uygulamanın mevcut davranışı ölçülebilir. Dolayısıyla performans testinin temelinde iki kavram vardır: Ölçüm + gerektiğinde kontrollü yük oluşturma.
2) Her Performans Testinin Bir Referans Noktası Olmalıdır
Performans testindeki en önemli metodolojilerden biri referans oluşturmaktır. Örneğin: 100 kullanıcı, 500 kullanıcı, 1.000 kullanıcı veya 5.000 kullanıcı şeklinde kontrollü olarak ilerlenebilir. Buradaki amaç sadece "5.000 kullanıcıda sistem çalıştı mı?" demek değildir. Asıl soru, 100 kullanıcıdan 500 kullanıcıya geçtiğimizde sistemin hangi metriklerinde ne kadar değişim meydana geldi? sorusudur. Aynı anda birden fazla değişkeni değiştirmek ise sonucu yorumlamayı zorlaştırır.
3) Test Datası Performans Testinin Gizli Kahramanıdır
Performans testlerinde en çok küçümsenen konulardan biri test datasıdır. Aynı kullanıcıyı sürekli kullanmak, aynı ürünü tekrar tekrar sorgulamak veya cache davranışını hesaba katmamak gerçek sistemi temsil etmeyen sonuçlar doğurabilir. Örneğin e-ticaret sisteminde: 100 kullanıcının aynı ürünü alması ile 100 kullanıcının 100 farklı ürün üzerinde işlem yapması aynı yük değildir. Database bağlantıları, cache davranışı ve arka plandaki servisler farklı şekilde çalışabilir. Bu nedenle performans tester'ının sistemi ve iş akışlarını anlaması gerekir.
4) Test Ortamı Production'a Mümkün Olduğunca Yakın Olmalıdır
Performans testinin sonucu, test ortamındaki Configuration nedeniyle tamamen yanıltılabilir. İdeal yaklaşım: Production'a mümkün olduğunca benzeyen temiz bir Pre-Production (PREPROD) ortamıdır. Uygulama versiyonu, configuration, cache, connection pool ve benzeri kritik parametrelerin production ile uyumlu olması önemlidir. Çünkü bazen tek bir configuration farklılığı bile test sonuçlarını geçersiz hale getirebilir.
5) Yükü Nereden Oluşturduğun Önemlidir
1000 sanal kullanıcı oluşturmanız tek başına iyi bir performans testi yaptığınız anlamına gelmez. Yükü oluşturan Worker/Load Generator ile test edilen uygulama arasındaki network de ölçümü etkileyebilir. Örneğin evdeki bilgisayardan internet üzerinden AWS üzerindeki uygulamaya yük gönderiyorsanız; router, internet bağlantısı, ISP ve network gecikmesi sonuçlara dahil olabilir. Eğer amaç uygulamanın kendisini ölçmekse load generator'ın uygulamaya mümkün olduğunca yakın olması gerekir.
6) KPI'ları Test Ekibi Tek Başına Belirlememelidir
"Bu API 500 ms altında cevap vermeli." veya "Bu sistem saniyede 15.000 işlem kaldırmalı." gibi hedefler doğrudan test ekibinin kafasına göre belirleyeceği değerler değildir. Test ekibinin temel görevi: ölçmek → analiz etmek → raporlamak. İş gereksinimine göre kabul edilebilir performans seviyesinin belirlenmesi ise Production tarafıyla birlikte ele alınmalıdır. Burada test ekibinin bağımsız "Üçüncü Göz" rolünü koruması da önemlidir.
7) Sadece Happy Path Test Edilmemelidir
Performans testinde: "Login başarılı oldu, ürün sepete eklendi, ödeme tamamlandı." demek yeterli değildir. Negatif senaryolar da performans açısından incelenmelidir. Örneğin: Yanlış kullanıcı adı/şifre, Servisin timeout vermesi, Dış servisin cevap vermemesi, Farklı ürünlerin sorgulanması, Servisin yavaş cevap vermesi, Entegrasyonun tamamen devre dışı kalması gibi durumlar sistemin gerçek davranışını ortaya çıkarabilir.
8) Dış Entegrasyonlar Gerektiğinde Mock'lanmalıdır
Örneğin uygulamanız bir ödeme kuruluşuna bağlanıyor. Binlerce sanal kullanıcıyla gerçek ödeme servisine yük gönderirseniz dış sistem sizi Rate Limit nedeniyle 429 hatasıyla engelleyebilir. Bu durumda aslında kendi uygulamanızın kapasitesini ölçmüyorsunuzdur. Bu nedenle dış entegrasyonlar performans testinde Mock/Simulation ile izole edilebilir. Fakat burada kritik nokta şudur: Mock sadece başarılı cevap vermemeli. Timeout, gecikme ve servis hatası gibi davranışlar da simüle edilmelidir.
9) Retry Storm Performans Açısından Ciddi Bir Tehdittir (Önemli)
Bir servis başka bir servisten cevap alamadığında tekrar deneyebilir. Örneğin: A → B → C isteğinde B cevap vermiyor. A tekrar deniyor. B yine cevap vermiyor. A tekrar deniyor. Üstelik retry yalnızca uygulama seviyesinde olmayabilir. Network veya başka altyapı katmanlarında da tekrar denemeler gerçekleşebilir. Bunlar üst üste geldiğinde sistem üzerindeki trafik katlanabilir ve sonunda Retry Storm ortaya çıkabilir. Bu nedenle timeout ve retry davranışları performans testinin önemli negatif senaryolarındandır.
10) Cache ve Database Davranışı Mutlaka İzlenmelidir
Uygulamanın başarılı cevap vermesi sistemin sağlıklı olduğu anlamına gelmez. Örneğin cache devre dışı kaldığında veya cache temizlendiğinde normalde cache üzerinden karşılanan istekler database'e yığılabilir. Sonuç olarak: Uygulama çalışıyor → database aşırı yükleniyor → database çöküyor. Bu nedenle performans testinde sadece response time'a bakmak yeterli değildir. CPU, RAM, database bağlantıları, connection pool, cache ve hata/log kayıtları da birlikte değerlendirilmelidir. Bu yüzden Performans Testi yaparken gözlemci olarak Database ve Orta Katman (DevOps) ekipleri testlere katılabilir.
Sonuç Olarak; Performans testinin amacı “sistem kaç kullanıcı kaldırıyor?” sorusuna tek bir sayı vermek değildir. Sistemin belirli bir yük ve çalışma koşulu altında nasıl davrandığını, nerede performans kaybettiğini ve bunun nedenini ölçülebilir verilerle ortaya çıkarmaktır. Bu nedenle iyi bir performans testi; doğru referans + doğru data + doğru ortam + doğru yük + gerçekçi senaryolar + negatif senaryolar + doğru metrikler + doğru raporlama kombinasyonudur. İyi bir performans tester'ı sistemi sadece ne kadar yük taşıdığını görmek için zorlamaz; sistemi neden zorlandığını anlayabilecek şekilde test eder. Bu yaklaşım performans testini basit bir araç kullanımından çıkarıp mimari, veri, altyapı ve iş senaryolarını birlikte değerlendiren mühendislik disiplinine dönüştürüyor.
Burak AVCI
Hiç yorum yok:
Yorum Gönder
Makaleye Yorum ve Sorularınızı Bırakabilirsiniz.