Uygulamanız çalışıyor. Her düğme tıklanıyor, her form gönderiliyor ve demo yönetim kurulunu büyüledi. Derken pazarlama ekibi bir kampanya başlatıyor, on iki bin kişi on dakika içinde ödeme sayfasına akın ediyor ve her şey çöküyor — zaman aşımları, 502 hataları, %100 CPU'da sabitlenmiş bir veritabanı. Kodda bir sorun yoktu. Ona ne kadar yük taşıyabileceği hiç sorulmamıştı.
İşte bu boşluk — "çalışıyor" ile "yük altında çalışıyor" arasındaki fark — tam olarak performans testinin yaşadığı yerdir. Amaç, sisteminizin hızlı olduğunu kanıtlamak değildir. Amaç, sistemin baş edemez hâle geldiği noktayı, kendi koşullarınızda, bir laboratuvarda, gerçek bir kalabalık sizin yerinize bulmadan önce keşfetmektir.
Performans testi aslında neyi ölçer
"Performans testi" bir şemsiye terimdir ve onu tek bir etkinlik gibi ele almak ilk hatadır. Altında birbirinden farklı sorular yatar:
- Yük testi (load testing) — sistem, normal yoğun bir günde beklediğiniz trafikte yanıt sürelerini koruyabiliyor mu?
- Stres testi (stress testing) — kırılma noktası nerede ve onu aştığınızda ne olur? Sistem zarafetle mi bozulur yoksa tümden mü çöker?
- Ani yük testi (spike testing) — trafik, bir televizyon anonsundan veya anlık bildirimden sonra olduğu gibi otuz saniye içinde 10 katına çıktığında ne olur?
- Dayanıklılık testi (soak/endurance testing) — sistemi orta düzey yük altında sekiz saat çalıştırın. Bellek sızıntıları, bağlantı havuzunun tükenmesi ve dolan bir günlük diski ancak zamanla yüzeye çıkar.
- Ölçeklenebilirlik testi (scalability testing) — sunucu sayısını iki katına çıkardığınızda çıktı da iki katına çıkıyor mu, yoksa paylaşılan bir veritabanı sizi 1,3 katında mı sınırlıyor?
Her biri farklı bir iş riskini yanıtlar. Kullanıcılarınızın gerçekte nasıl geldiğine karşılık gelenleri seçin.
Kırılma noktası bir felaket değil, veridir
Mühendisler, sistemin çöktüğü anı kaçınılması gereken bir şey olarak görür. Bense onu bu çalışmadaki en değerli tek sayı olarak görüyorum. Kırılma noktanızı bilmiyorsanız, kapasiteyi tahmin ediyorsunuz demektir — ve ya fazla kaynak ayırıp para yakarsınız ya da az kaynak ayırıp güveni yakarsınız.
Bunu bulmak için, trafiği kademeli olarak artırırken üç sayıyı izlersiniz:
- Çıktı (throughput) — sistemin saniyede başarıyla işlediği istek sayısı.
- Gecikme, yüzdelik dilimlerde — ortalama değil. Ortalama, rahatlatıcı bir yalandır. Ortalama yanıt süreniz 200 ms ama p99 değeriniz 6 saniyeyse, her yüz kullanıcıdan biri berbat bir deneyim yaşıyordur — ve ölçekte bu, binlerce kişi demektir.
- Hata oranı — hatalar tırmanmaya başladığı an, eğrinin dirsek noktasını bulmuşsunuz demektir.
Kırılma noktası çöküş anı değildir. Yanıt sürelerinin fırladığı ve hataların başladığı andan hemen önceki yük düzeyidir — gerçek kapasite tavanınız işte budur.
Kendinizi kandırmadan bir test yürütmek
Çoğu performans testi aynı öngörülebilir şekillerde yanlış yapılır. İşe yarayan bir test şöyle görünür:
- Gerçek trafiği modelleyin. Gerçek istek dağılımınızı canlı ortam günlüklerinden çekin. Ucuz tek bir uç noktayı döven bir test size hiçbir şey söylemez; gerçek kullanıcılar dağınık oranlarla giriş yapar, arama yapar, sepete ekler ve ödeme yapar.
- Başlamadan önce hedefleri belirleyin. SLO'yu baştan kararlaştırın — örneğin, "2.000 eşzamanlı kullanıcıda p95 500 ms'nin altında, hata oranı %0,1'in altında." Karşısında geçilecek veya kalınacak bir sayı olmadan, yalnızca grafik üretmiş olursunuz.
- Canlı ortama benzer bir şeyi test edin. Bir dizüstü bilgisayarda ya da tek başına güçsüz bir hazırlık (staging) makinesine karşı yapılan yük testi, dizüstü bilgisayarı ölçer. Aynı örnek türleri, aynı veri hacmi, aynı ağ yolu.
- Aniden yüklemeyin, kademeli artırın. Yükü aşamalar hâlinde artırın ve her düzeyde bir süre tutun. Eğrinin nasıl büküldüğünü izlemek istersiniz; yalnızca tek bir darbeye dayanıp dayanmadığını değil.
- Yük üretecini değil, sistemi izleyin. İstemci size yanıtların yavaşladığını söyler. Sunucu — CPU, bellek, veritabanı bağlantıları, kuyruk derinliği — bunun nedenini söyler. O "neden", işin bütün özüdür.
Araç seçimi işin kolay kısmıdır. k6 ve Locust, testleri kod olarak yazmak isteyen mühendisler için keyiflidir; Gatling ve JMeter ise güvenilir birer beygir olmayı sürdürüyor. Aracın kendisi, ona verdiğiniz iş yükü modelinden çok daha az önemlidir.
Nereden başlamalı
Canlı ortamda çalıştırdığınız şeyi hiç yük testine tabi tutmadıysanız, görkemli bir test platformu tasarlamayın. En önemli tek kullanıcı yolculuğunuzu seçin — genellikle ödeme, giriş veya arama — onu gerçekçi oranlarla sürükleyen bir betik yazın ve bir şey kırılana kadar yükü artırın. O ilk kırılma sayısı, size gerçek kapasiteniz hakkında bir çeyrek boyunca gösterge paneli izlemekten daha fazlasını anlatacaktır.
Ardından onu iş akışınıza (pipeline) yerleştirin ki bir sonraki gerileme, bir müşteriyi değil bir testi düşürsün. Kırılma noktası her hâlükârda bulunacaktır. Tek soru, onu önce sizin bulup bulmadığınızdır.