Yoğun Yük Beklenen Sistemlerde Performans Analizi
Yazılım projelerinde ön görülmesi zor şeylerden biri yoğun yük altında çalışınca yaşayacağı performans problemleridir. Deneyimli yazılımcılar bazı noktaları ön görebilse de bazen takım içerisindeki deneyimsiz yazılımcıların geliştirdiği hatalı kodlar, bazen de gözden kaçan konfigürasyonlar nedenli hatalar sebebiyle uygulamada ciddi problemler oluşabiliyor.
Bunu engellemek için birkaç yöntem önerebilirim.
Birincisi devreye alım öncesinde yük testleri yapmak sizi geliştirdiğiniz ürün veya mevcut ürüne eklediğiniz özelliğin oluşturabileceği problemleri görmenizi sağlayabilir. Açık kaynak veya ücretli birçok yük testi ürünü var. Benim önerim açık kaynak JMeter ve Gatling olabilir. Eğer anlık yük oranı 1.000 request ve üzerinde bir değere çıkacaksa bu ürünleri dağıtık hale getiren Blazemeter veya Loadium gibi araçlar kullanabilirsiniz.
Yük testleri koşarken çok fazla yapılan hata yükün ne olduğu üzerine. Burada çok fazla kafa karıştıran terim var. Bunların tanımlarını aşağıda listeledim.
Request per Second: Anlık gelen talep sayısı
Concurrent Session: Anlık session yani oturum sayısı
Transaction per Second: Saniyede karşılanan transaction sayısı
Bunlar birbirinden farklı değerlerdir ve bazen aynı dili konuşmakta zorluk yaşayabiliyoruz. Bir sisteme saniyede gelen request sayısı ciddi bir değerdir. Mesela bu rakam 500 dersek ilk başta küçük bir değermiş gibi görünebiliyor ancak saniyede 500 request dakikada 30.000 talep demek ki aşağıda internetlivestats.com aldığım bazı istatistikler var.
Tweeter’a tüm dünyada saniyede gelen tweet sayısı 9.298
Instagram’a tüm dünyada saniyede yüklenen fotoğraf sayısı 1.043
Google’da tüm dünyada saniyede yapılan arama sayısı 88.731
YouTube’ta tüm dünyada saniyede izleme sayısı 87.656
Gördüğünüz gibi saniyede sisteme 20.000 request bekliyorum derken gerçekçi olmakta fayda var. Burada en çok karıştırılan şey sisteme aktif yapılan sorgu ile sistemde gezen kullanıcı değeri diyebiliriz. Yani siz Gittigidiyor gibi bir web sitesine girdiğinizde bir arama yaparsınız ve sonra birkaç saniye sonuçlar üzerinde gezer ve beğendiğiniz ürüne tıklarsınız. Bu bir kullanıcı için 5-20 saniye süren bir işlem olabilir. Dolayısı ile siz arka arkaya sisteme yük bindirmemiş olursunuz. Bu durumda beklenen sistemde 20.000 aktif kullanıcı olması ama saniyede gelen yük sayısının 500-2.000 arasında olmasıdır. Bu ayrımı doğru yapmak lazım.
Peki kabul edilebilir performans değerleri nelerdir. Bunun için Apdex denen bir standart var. Apdex, bilgisayar uygulamalarındaki yazılım uygulamalarının performansını ölçmek için açık bir standarttır. Amacı, ölçülen performansın kullanıcı beklentilerini ne ölçüde karşıladığını analiz etmek ve raporlamak için tek tip bir yol belirleyerek ölçümleri kullanıcı memnuniyeti ile ilgili içgörülere dönüştürmektir. Bu tanımı Wikipedia’dan kopyaladım. Apdex’e göre aşağıdaki gibi 3 değer var.
Satisfied: Memnun edebilir performans
Tolerating: Tolere edilebilir değerlerde
Frustrated: Tolere edilebilir değerlerin dışında. Hayal kırıklığı.
Daha detaylı bilgiye New Relic sitesi ve Apdex.org’ tan ulaşabilirsiniz.
Peki yük testi yaptığımız uygulamalarda olası problemleri nasıl adresleriz. Aslında bunun için APM (Application Performance Monitoring) araçlarını kullanabilirsiniz. En popüler olanları New Relic, Dynatrace ve AppDynamics’tir. Biz yük uyguladığımız sistemlerin arka planını bu araçlarla izliyor ve analiz ediyoruz. Bu araçların en güzel tarafı bir ajan vasıtası ile bytecode instrumentation ile izledikleri sistemin tüm detaylarını vermesi. Bu sayede olası yavaşlıkların tam olarak nerelerden kaynaklandığını görme şansınız oluyor. Eğer şirkette bu gibi bir araç kullanıyorsanız yük testi yapmadan önce ajanın eklenmesini ve size bir kullanıcı açılmasını talep edin derim. Bu sayede oluşan problemle ilgili tüm detayları almış olursunuz.
