次の方法で共有

Web uygulamalarında performansa dair...

  • [アーティクル]

Performans sorunları, bize, yani yazılım geliştirme desteği bölümüne, en çok gelen sorun türlerinden biridir. Aslında bunun en temel nedeni, yazdığımız uygulama tamamlanıp, kullanıma açılana kadar; ve performans kaynaklı bir sıkıntı ortaya çıkana kadar performans konusuna kaynak aktarılmıyor olmasıdır. Pek çok durumda yük/stres testleri yapılmadan uygulama kullanıma açılıyor. Testler yapılsa bile çok gerçekçi ortamlarda, gerçekçi yüklerle yapılmayabiliyor.

"Uygulamamızda performans sorunu yaşıyoruz!"

Performans, bugüne kadar verdiğim eğitimlerde de çokça dile getirdiğim gibi, tamamen göreceli bir kavramdır. Yani birisi size "uygulama yavaş çalışıyor" dediğinde, bundan ne anlarız? Yanıt vermesi 3 dakika mı sürüyor? Yoksa 15 dakika mı? Belki de 30 saniye...

Uygulamaya ve elbette kullanıcının beklentisine göre yukarıda verdiğim süreler normal de olabilir, hızlı da, yavaş da. İşte tam olarak bu nedenle, bize performans sorunları geldiğnde, önce uygulamanın ne yaptığını, "yavaşlık" kavramının tanımını ve beklentiyi öğrenmeye çalışırız. Sonra, bu durumun ne zaman ve ne şekilde ortaya çıktığını araştırırız. Örneğin uygulama üzerindeki yük artışına bağlı bir yavaşlama söz konusu olabilir. Böyle bir durumda performans sorunu yaşandığını söylemek elbette çok doğru olmayacaktır.

Somut rakamlar

Her türlü sorunun iki farklı tanımı vardır: Objektif (nesnel) ve subjektif (öznel) tanım. Yukarıda bahsettiğim sorular subjektif tanımı yapmak açısından gerekliydi. Ancak sonuçta bir "mühendis" ya da "teknik" birisi olarak bizim somut, yani objektif verilere ve rakamlara da ihtiyacımız olacaktır.

İşte bu rakamları toplayabileceğimiz, web uygulamaları ve IIS ortamlarından bahsederken, iki yer bulunuyor: IIS logları ve performans sayaçları.

IIS logları, o uygulamaya geçmişte ve bugün ne kadar istek geldiğini görebileceğimiz yerdir. Bu tür istatistiki bilgileri, daha önce bir blogumda bahsettiğim LogParser aracıyla çıkarabiliriz. Ayrıca, IIS loglarında "time taken" parametresinin değerini de tutuyorsak, geçmişten bugüne isteklerin yanıtlanma sürelerindeki değişimi de gözleyebiliriz.

Performance Monitor (perfmon.exe)  

Performans sorunları yaşadığımızda, veya bundan şüphelendiğimizde ilk bakmamız gereken yerlerden biri perfmon.exe olmalıdır. Sıradan bir Windows 2003 sunucuda onlarca performans nesnesi, ve toplamda binlerce sayaç bulunur. Elbette bunların hepsi her zaman işimize yaramayacaktır. Ve elbette bunların tümü hakkında bilgi sahibi olmamızda gereksizdir.

IIS üzerinde çalışan web uygulamaları için bile yüzlerce sayaç bulunmaktadır. Bunların tamamına ihtiyaç duyabileceğimiz zamanlar olabilir. Ancak, her koşulda ilk kontrol edilmesi gereken birkaç tanesini aşağıda bulabilirsiniz. Bunların dışındaki sayaçlara da bir göz atıp,nasıl sorunlarda hangilerini izlemeniz gerektiğini önceden bilmek ileride bize çokça vakit kazandıracaktır.

  • .NET CLR Exceptions\# of exceptions thrown/sec: Saniyede kaç "exception" alındığını gösterir. İdeal olan her zaman sıfır olmasıdır ama bu pratikte pek mümkün değildir. Ne kadar düşük olursa o kadar iyi diyebiliriz.
  • ASP.NET\Application restarts: "Application pool"un değil, üzerinde çalısan uygulamanın kaç defa yeniden başlatıldığını gösterir. Bunun da uygulama ortamlarında sıfır olmasını bekleriz. Eğer bu sayı sürekli artıyorsa ortada bir sorun olduğu kesindir. Buradaki makalemde bunun olası nedeni anlatılmatılmaktadır.
  • ASP.NET\Request execution time: En son isteğin ne kadar sürede yanıtlandığını gösterir. Yavaşlık olup olmadığını tam olarak buradan anlayabiliriz.
  • ASP.NET\Requests queued: Herhangi bir anda kuyrukta bekleyen istek sayısını gösterir. Genelde bunun da sıfır olmasını bekleriz. Anlık olarak biraz yükselip düşmesi de normaldir (Garbage Collector devreye girdiği anlarda örneğin).
  • ASP.NET\Worker process restarts: "Application pool"un kaç defa restart olduğunu gösterir. Bu sıfırdan farklıysa olay günlüklerini (event log) incelemek gerekir.
  • ASP.NET Applications\Requests/sec: Uygulamamıza saniyede gelen ortalama istek sayısını verir. Bunun için belirli bir rakam vermek mümkün değildir. Hem uygulamanın mimarisine hem de donanıma bağlıdır. Burada göreceğimiz rakamı sorunsuz bir zamandakiyle karşılaştırıp yük artışı mı var sorusunun yanıtını aramak gerekir.

Yukarıdakiler ve diğer başka sayaçlarla ilgili detayları aşağıdaki bağlantılarda bulabilirsiniz:

Performance Counters for ASP.NET
Performance Counters in the .NET Framework

Sorun ihtimaline hazırlık

Yukarıda da belirttiğim gibi, performans göreceli bir kavramdır. Ancak bu konuyu üzerinde çalışılabilir hale getirmenin de bir yolu vardır. Bunun için, sorun anında toplayacağımız verileri karşılaştırabileceğimiz, baz alabileceğimiz verilere ihtiyacımız olacaktır. İşte tam olarak bu nedenle, örneğin aylık periyotlarda, herşeyin sorunsuz çalıştığı ve rakamların beklentilerimizi yansıttığını düşündüğümüz bir anda performans logları toplayıp bir kenara kaydetmeliyiz. Bu amaçla toplayacağımız loglar, mümkün olduğunca fazla sayaç içermelidir. Örneğin ASP.NET uygulamalarımız varsa en azından şu sayaçların loglarını toplamalıyız:

  • .NET CLR ile başlayan tüm nesneler
  • ASP.NET ile başlayan tüm nesneler
  • Process
  • Processor
  • Memory

Elbette bu nesnelerin "tüm sayaçları" ve "tüm programlar" için toplanmalıdır.

SONUÇ:

Her uygulamada zaman zaman performans sorunları yaşanabilir. Önemli olan, diğer sorun türlerinde olduğu gibi, bunu bilip, buna hazırlıklı olmaktır. Sorun oluştuktan sonra bazı verileri toplayabilmek veya bazı yorumları yapabilmek için çok geç kalmış olabiliriz.

CENK ISCAN