ASP.NET uygulamalarında ACT ve NProf ile Performans Testi

Yazilim gelistirme projelerinin sonunda genellikle çalisir
bir program elde edilmeye çalisilir. Müsteri isteklerinin kaçta kaçina cevap
veriyor veya performans, ölçeklendirme ve gövenlik konularina ne kadar agirlik
verilmis pek önemsenmez. Hal böyle olunca yazilimin; yukarida bahsettigim
özelliklerinin test edilmis olmasi çok küçük bir ihtimal gibi geliyor bana.

Ürünün piyasaya çikis zamani ve özellikleri pazarlama ekibi için yeterli kistas
olmamalidir. Ürün bu düsünceler ile satildiginda müsteriden gelecek sorular
yanitsiz kalabilir. Örnegin, bu yazilim kullanici hatalarina karsi ne kadar
dayanikli, sürekli büyüyen ve gelisen müsteri portföyüme göre ölçeklendirme
yapilabilir mi, hangi güvenlik yöntemleri yazilimda uygulanmistir, bu yazilimi
mevcut BT altyapimiza nasil entegre edebiliriz, destek anlasmasi ne kadar tutar
gibi sorular sorulmasi ve çok iyi biçimde cevaplandirilmasi gereken sorulardir.
Bu sorular ürününüzün kurumsal özelliklerini belirler.

Bu yazinin amaci ASP.NET uygulamalarinin performans açisindan ele alinarak
gelistirilmesi ve NProf ile Microsoft’un Application Center Test uygulamalarinin
nasil kullanilacagini anlatmaktir. Öncelikle genel bir yaklasim ile nicelik
olarak performans degerlendirme islemine ve sonra da NProf ve ACT araçlarinin
kullanimina bakacagiz.

Performans Yaziliminizin bir Özelligidir

Performans özelligi yaziliminizin kurumsal özelliklerinden bir tanesidir. Kaç
kullanici ayni anda kullanacak, veri tablolarinin tutacagi veri miktari, ag
yapisinin veri tasima hizi ve miktari, veritabanindan çekilecek verinin miktari,
yazilimin kullandigi hafiza miktari ve disk alani nicel olarak sayilara
dökülmelidir. Bir mühendis için subjektif ölçütlerin önemi yoktur bu yüzden
dogru bir degerlendirme için bu rakamlarin belirlenmesi gerekir. Gelistirdiginiz
uygulamanin ne kadar hizli oldugunu nasil ölçersiniz? Uygulamaniz PII 400Mhz bir
bilgisayarda iki kullanici ile isik hizinda çalisabilir fakat Xeon 2Ghz bir
bilgisayarda ve 2000 kullanici ile ne sonuç verecektir?

Müsteri isteklerini degerlendirme asamasinda kaç adet kullanicinin ayni anda
uygulamayi kullanacagini ortaya çikarmaniz sarttir. Eger donanim gereksinimleri
belli degil ise, yazilim gelistirme ekibi bunu göz önünde bulundurmalidir. Bu
durumda performans degerlendirmede kullanilacak 4 ana unsuru ortaya çikiyor.
Bunlar:

Yanit verme hizi
Kullanicinin donanim özellikleri
Ayni anda kullanan kullanici miktari
Gelistirdiginiz yazilim veya programlama algoritmasi

Örnegin uygulamanin yanit verme hizini 10 saniyeden 5 saniyeye düsürmek
istiyorsunuz. Bu hedefe “Ayni anda kullanan kullanici miktarini” düsürerek
ulasabilirsiniz yada ek donanim ekleyerek veya yazdiginiz kodu tekrardan gözden
geçirerek. Yada bu üçünü bir kombinasyon halinde kullanabilirsiniz.

Ayni anda kullanan kullanici miktarini belirlemek

Yaziliminizi kullanan tüm kullanicilar ayni anda ayni islemleri yapmak için web
gezgininin karsisina oturmayabilir. Eger bir firma için sadece iç-örütbaginda
(intranet) çalisacak bir uygulama gelistiriyorsaniz ve firmanin 4000 adet
çalisani varsa bu 4000 potansiyel kullanici demektir.

Genel olarak potansiyel kullanici sayisini bulduktan sonra bunlardan kaçinin bir
gün içinde ASP.NET uygulamasini kullandigini bulmak gerekir. Örnegin uygulamaniz
çalisma saatlerinin tutuldugu bir uygulama ve %25 oraninda her gün kullaniliyor.
Bu durumda 1000 adet kullanici her gün uygulamanizi kullaniyor demektir. Bu
kullanicilar günde kaç saat bu uygulamayi kullanabilir? Eger bahsettigimiz
firmanin çesitli ülkelerde ofisleri varsa 24 saat boyunca herhangi bir an
olabilir, sadece Türkiye içindeki ofislerde kullaniliyorsa günlük 8 saat gibi
bir zaman ortaya çikar. Erken gelen ve geç çikan ofis çalisanlarini da göz önüne
aldiginizda 3 saat daha ekleyebiliriz. Son olarak kullanicin uygulama ile
geçirdigi zamani belirlememiz gerekiyor. Çalisma saatlerinin tutuldugu bir
uygulamanin 15 dakikadan fazla kullanilacagini tahmin etmiyorum. Tabii ki bu
veriyi müsteriniz ile görüsüp dogrulamaniz gerekmektedir.

Yukaridaki veriler isiginda asagidaki formülleri kullanarak tahmini ayni anda
kullanan kullanici sayisini bulabiliriz.
Günlük toplam kullanici miktari g = 1000
Saat basina düsen kullanici miktari s
Günlük çalisma saati çs = 11
Her saat için desteklenen kullanici miktari hkm
Uygulama ile geçirilen zaman gz = 15dk
Ayni anda kullanan kullanici sayisi kk
Günlük kullanici sayisi gks

g = 4000*0,25 = 1000 kullanici
s = g / çs = 1000/11 = 90 kullanici\saat
hkm = 60dk / gz = 60/15 = 4 kullanici\saat
kk = s / hkm = 90/4 = 22,5 kullanici
gks =( (çs * 60dk) / gz) * kk = ((14saat * 60dk) / 15dk) * 22,5 = 1260
kullanici\gün

Her uygulamanin yogun olarak kullanildigi zamanlar vardir. Örnegin e-posta
sabahlari daha çok kullanilir. Sizin uygulamaniz için yogun olabilecek zamanlari
müsteriniz ile görüsüp belirlemeniz gerekir.

Genelde %300 oraninda yogunluk normal olarak karsilanabilir. Bu durumda kk
degerini 3 ile çarparsak, 67,5 kullanici yogun zamanlarda uygulamanizi kullanmak
isteyecektir.

Tüm bu kullanicilarin sürekli sayfalar arasinda gezineceklerini ve ag sunucunuzu
mesgul edecegini düsünmeyin. Kullanici bir linke veya tusa tiklayacak ve
sayfanin ag gezgini içinde görüntülenmesini bekleyecektir. Tekrar baska bir
linke veya tusa tiklamak için önce sayfayi okuyacak ve tiklayacagi linke veya
tusa karar verecektir. Endüstri standardi olarak her sayfa 5 ile 10 saniye
arasinda ag gezgininde görüntülenmelidir. Kullanici 5 ile 15 saniye arasinda
sayfada ne görüntülendigini kavrar ve tiklayacagi tus yada linke karar verir. Bu
bilgiler isiginda diyebiliriz ki kullanici her 10 ile 25 saniyede bir sunucudan
istekte bulunacaktir.

Bize gerekli olan 1 saniyede sunucudan istenen sayfa sayisini ve uygulamanin
cevap verme hizini bulmaktir. Örnegimizde bir kullanicinin uygulama ile 15
dakika harcayacagini zaten biliyoruz. Bu durumda yukaridaki endüstri
standartlarini kullanarak ayni anda aktif olarak kullanan kullanici sayisini
daha gerçekçi olarak bulabiliriz.

Kullanici basina düsen sayfa istegi kbd
Iki sayfa arasinda geçen zaman sag = 10 ile 25sn arasi
1 saniyedeki sayfa istegi ssi
Yogun zamanlardaki kullanici miktari yzk = 67,5
kullanici

kbd = gz * 60saniye / sag = 15dk * 60 / 10saniye = 90sayfa
ssi = kbd * yzk / gz * 60saniye = (90sayfa * 67,5 kullanici) / (15dk * 60sn) =
6,75 sayfa\saniye
kk = (ssi * gz * 60sn) / kbd = (6,75 * 15dk * 60sn) / 90sayfa = 67,5 kullanici

Buradan çikan sonuçlar her mühendisin rahatlikla ACT yada baska bir performans
test araci kullanarak test edebilecegi sonuçlardir ve kk degeri ile istenen
performans kriterine ulasmak için gerekli donanim gücü de hesaplanabilir.

Application Center Test ile performans degerlendirme

Buraya kadar ev ödevimizi yaptiktan sonra ACT kullanarak performans
degerlendirmesi yapabiliriz. Application Center Test, Visual Studio.NET
Enterprise Developer yada Enterprise Architect sürümleri ile beraber geliyor ve
kullanimi oldukça basit. “Programs / Microsoft Visual Studio.NET / Visual
Studio.NET Enterprise Features / Microsoft Application Center Test” menüsünden
çalistirabilirsiniz. Öncelikle File / New menüsünden yeni bir proje yaratin. Bir
isim vererek kaydedin. Test senaryolarini Action / New Test menüsünden
olusturacagiz. Bu menü seçenegini seçtiginizde karsiniza senaryo hazirlama
sihirbazi gelecektir. Next tusuna tiklayip “record a new test” seçenegini seçin
ve tekrar Next tusuna basin. Sonraki adimda script dilini seçin (simdilik sadece
VBScript). “Start Recording” tusuna basinca karsiniza bir ag gezgini çikacak.
Buradan sonra normal bir kullanici gibi sitenizi ziyaret edin. Eger varsa, uzun
süren veritabani islemleri veya uzak sunuculardan veri çekme gibi islemleri
yapin. Isiniz bitince ag gezginini kapatin ve “Stop recording” tusu yardimi ile
islemi sonlandirin. Next tusuna bastiktan sonra olusturdugunuz test senaryosunu
bir isim vererek kaydedin.

Kisaca ag gezgini ile yaptiginiz her islem VBScript olarak kayit edildi. Bu
senaryoyu defalarca çalistirabilir ve hafizada neler olup bittigine bakabiliriz.
ACT’nin ana ekranina geri döndügünüzde sol taraftaki bölümde “Tests” basamagini
genisletin. Kayit ettiginiz test senaryosu bu basamagin altinda yer aliyor. Test
senaryosu üzerine sag tiklayip “Start Test” seçenegi ile testi tekrardan
baslatabilirsiniz. Sag taraftaki “Test Status” bölümü testin çalisma sirasindaki
durumunu göstermektedir.

Sol kösede testin ne kadar zamandir çalistigini ve sag kösede de istek/saniye
(requests/sec) ve toplam yapilan istekleri görebilirsiniz. Alttaki grafik ise
islenen istekleri göstermektedir. Bu grafik, yukaridaki formüllerde geçen ssi
degerini temsil etmektedir. Bitince “Stop Test” tusuna basarak testi durdurun ve
test tamamlaninca da Close tusu ile ekrani kapatin.

Ana ekranda sol taraftaki agaç yapisinda “Results” dali altinda testin
sonuçlarini görebilirsiniz. “Test runs” listesi size calistirilan tüm testleri
listeleyecektir. Herhangi bir testin üstüne tikladiginizda o test ile ilgili
bilgiyi ekranin sag tarafinda göreceksiniz. Sag üst kösedeki “Report”
listesinden “Requests” seçenegini seçtiginizde “Time To First Byte” (TTFB) ve
“Time To Last Byte” (TTLB) degerlerini göreceksiniz. Örütbag sunucusunun aldigi
istekleri ve bu istek dogrultusunda ilk byte’in ag gezginine döndürüldügü
zamanlari görebilirsiniz. TTFB zamani sayfanin islenme süresini göstermektedir.
TTLB ise sayfanin web gezginine tamami ile döndürüldügü zamani gösterir.TTLB –
TTFB ise sayfanin ag üzerinde harcadigi zamani verecektir. Ortalama TTFB ve TTLB
zamanlari 10 saniyenin üstüne çikmamalidir.

Eger ACT’nin ürettigi VBScript’lere bakacak olursaniz fEnableDelays’in “false”
oldugunu göreceksiniz. Bu sayfa istekleri arasinda bekleme olmadigi anlamina
gelir. Yani kullanici hiç beklemeden bir sonraki sayfaya atlamis gibi. Gerçege
yakin bir test yapmak istiyorsak her sayfa arasinda 5 ile 15 saniye arasinda
bekleme zamani koymamiz gerekir. fEnableDelays degiskenini “true” yapin ve her
fonsiyonun basindaki Test.Sleep() fonksiyonunu Test.Sleep(5000) olarak
degistirin. Sleep fonksiyonuna geçirilen deger milisaniye oldugu için 5000 = 5
saniye olmaktadir. Sayfalarinizin büyüklügüne göre her sayfa için bir bekleme
süresi tayin etmeniz testlerin daha gerçekçi olmasini saglar.

Biraz daha detaylandiralim

Gördügünüz gibi ACT kullanarak uygulamanin kaldirabilecegi ssi degerini
görebiliyoruz. ACT her yazilim mühendisi için gerekli bir araç. Projenin
basindan itibaren ve sikça kullanilmalidir. Ssi degerini görmenin disinda hangi
metodlarin kaç defa çagirildigini ve ne kadar zamanin harcandigini da görmek
isteyebilirsiniz. Burada NProf devreye giriyor. NProf ile uygulamaniz için bir
çalisma profili çikarip analiz edebilirsiniz.

NProf’u sadece performans problemleri ile karsilastiginizda degil her zaman
kullanmanizi tavsiye ederim. Hangi metodda ne kadar zaman harcandigini bulabilir
ve performans problemlerinin gerçekte nerelerden kaynaklandigini bulabilirsiniz.
ASP.NET sayfalariniz hizli bile olsa, kaynaklari serbest birakacak küçük bir
degisiklik daha da hizli olmalarini saglayabilir.


http://NProf.sourceforge.net/Site/SiteHomeNews.html
adresinden NProf’u
indirebilirsiniz. Kurulum için asagidaki adimlari takip edin:
1- Zip dosyasini her hangi bir dizine açin
2- RegisterProfilerHook.bat batch dosyasini çalistirarak registration
kayitlarini tamamlayin

VS.NET add-in’i içinde:
1- RegisterVSNetAddin.bat dosyasi ile registration islemini tamamlayin
2- VS.NET’i açin
3- Bir proje yada solution açin
4- Tools menüsünden NProf’u yükleyebilirsiniz.

Kurduktan sonra NProf.Application.exe ile çalistirin. File/New menüsünden
profilini çikaracagimiz uygulama tipini seçin (ASP.NET). “Create Project” tusuna
basin ve “Project/Start project run” menü seçeneginden uygulamayi baslatin.
ASP.NET seçtigimiz için NProf IIS ve ASP.NET servislerini tekrar baslatacak,
çünkü NProf CLR profiling API’lerine bagimlidir ve uygulama process’ine
baglanabilmek için servisleri tekrar baslatmasi gerekmektedir.

NProf ASP.NET servisine profiling API’lerini kullanarak baglandigi için
uygulamaniz 20 kat daha yavas çalisacaktir. Bunun sebebi ölçümlerin profiling
API’ler yolu ile yapilmasi ve her nesne ve metod çagiriminda kayit edilmesidir.

NProf ile ASP.NET servisine baglandiktan sonra ASP.NET uygulamanizi normal
olarak kullanmaya baslayabilirsiniz. Önceden hazirladiginiz test senaryolari
dogrultusunda testlere baslayin. Eger senaryo bazli testleri tek tek test etmek
isityorsaniz her test senaryosu sonunda NProf’u durdurmaniz gerekiyor. Test
bitince NProf’a dönüp “Project/Stop project run” menüsünden profil yaratma
islemini durdurabilirsiniz. Eger Windows 2003 ve IIS6.0 kullaniyorsaniz az önce
seçtiginiz menü adimindan NProf durmayacaktir (bilinen bir hata, yeni sürümlerde
düzelecek). IIS Manager’i açin ve uygulamanizin dahil oldugu application pool’u
durdurun. Eger uygulamaniz “Default Web Site” altinda çalisiyorsa; Application
Pools/DefaultAppPool üzerine sag tiklayip “Recycle” seçenegini seçin. Bu durumda
IIS mevcut ASP.NET uygulamasini sonlandirarak yeni bir tane baslatir. Bu islem
NProf tarafindan algilanir ve profilleme islemi durur.

Buraya kadar performans degerlendirmesinde kullanacagimiz veriyi toplamak ile
ugrastik. Bundan sonra veriyi nasil analiz edecegimizi görecegiz.

Profil Verisini Analiz etmek

NProf ekraninda sol üst kösede “Thread” drop-down seçeneklerini göreceksiniz. Bu
drop-down uygulamanizin yarattigi tüm threadleri gösteriyor. Her thread farkli
bir nesne yada metod çalistirmaktadir. Buradan analiz etmek istediginiz thread’i
seçiniz. Sol taraftaki agaç yapisinda seçilen thread’in “namespace” yapisi ve
çalistirilan tüm tipleri görülecektir. Her namespace ve tipinin yaninda bir
isaretleme kutusu bulunmaktadir. Bu isaretleme kutusu istediginiz nesne veya
metod çagirimlarini süzmek için kullanilir. Kendi programiniza ait namespace
veya nesneleri seçerek sadece size ait verinin görüntülenmesini saglayin. En
tepede bulanan “All Namepsaces” isaretleme kutusundaki isareti de kaldirin
böylece tüm namespace’ler görüntülenmeyecektir.

Sag üst panel çagirilan nesne veya metodlari gösterecektir. Diger bes kolonda
her metod için profilleri gösterir:
# of Calls – Metodun kaç kere çagirildigini gösterir.
% of Totals – Toplam calisma zamaninin yüzde kaçinin bu metodda
harcandigini göstermektedir. Toplam çalisma zamani tüm threadleri kapsadigindan
burada gösterilen zaman rölativdir. Ayrica Profiling API yüzünden olusan yükü de
unutmayalim. Eger metoddan baska bir metod çagiriliyorsa her çagirilan metodun
çalisma zamani da buna eklenmektedir. Bir metodu seçtiginizde sag alt panelde
metodun çagirdigi diger metodlar gözükecekdir.
% in Method – Bir metod için toplam çalisma zamanini verir.
Çagirilan diger metodlarin çalisma zamanlari hariç tutulmustur. Eger bu kritere
göre listeyi siralarsak, en fazla zamanin hangi metodda harcandigini buluruz.
Buda bize iyi bir baslangiç noktasi verir.
% in Children – Çagirilan metodlarda geçen toplam çalisma
zamanini gösterir. Yüksek yüzdeli metodlar gene bakilmasi gereken metodlardir.
% Suspended – Thread’in ne kadar zaman “suspended” konumunda
bekledigini gösterir. Sifirdan farkli bir deger gösteren metodlar ilgilenilmesi
gereken metodlardir.

Sag üst panelde bir metodu seçtiginiz zaman sag alt panelde de metodun çagirdigi
diger metodlar listelenecektir. Bu listedeki ayrintilara bir bakalim.

# of Calls – Metodun kaç kere çagirildigini gösterir. Sadece
ana metoddan çagirildigi degil uygulama boyunca kaç kere çagirildigidir.
% of Total – Çalisma zamaninin yüzde kaçinin bu metodda
harcandigini gösterir. Yukaridaki gibi sadece ana metoddan çagirilma zamani
degil tüm metodlardan çagirilma zamanidir.
% of Parent – Ana metodun harcadigi toplam çalisma zamaninin
yüzde kaçinda bu metodun çalistigini gösterir. Bu kolonun genel toplami %100
vermelidir fakat yuvarlama hatlarindan dolayi 1 eksik veya 1 fazla çikabilir.

Her iki listeyide kolon basliklarina tiklayarak dizebilirsiniz. Elde ettiniz
data ile biraz zaman harcadiginizda ve kavramlar oturmaya basladiginda daha iyi
anlamaya baslayacaksiniz. NProf darbogaz yaratan metodlari veya nesneleri bulmak
için çok yararli bir araç. Bir kere fazla zaman harcayan metodlari
belirlediginizde, koda geçerek neden bu kadar fazla zaman harcandigini bulmaya
çalisin. Gerçekten zaman harcayan ve uzun bir islem yapan metod olabilir.
Yapilan uzun islemi parçalara ayirabilirseniz ayirin. Yada gerçekten bu metodda
bu kadar uzun zaman harcanmasini ve gerekli oldugunu dogrulamak için kod içine
bir kaç yorum satiri ekleyebilirsiniz.

Bir uyari olarak söylemek isterim ki; kodu optimize edecek bir yol buldugunuzda
hemen uygulamaya geçmeyin. Bu optimizenin etkileyecegi diger programlari veya
veriyi düsünerek hareket edin. Eger Degisiklik ve Istek Yönetimi ekibiniz varsa,
yapilan degisikliklerin onaylanmasi ve maliyetinin çikartilmasi gerekir. Eger
optimizasyon için kod üzerinde harcanacak zaman çok fazla ise ve geriye çok az
bir performans kazandiracaksa, optimizasyonu yapmanin bir anlami yoktur.

Sonuç

Application Center Test ve NProf iki ücretsiz araç ve yazilimdaki performans
darbogazlarini belirlemek için kullanilmasini tavsiye ediyorum. Performans
problemlerini ne kadar önce belirlersek, düzeltmeside o kadar az maliyetli olur.
Bu yüzden projelerin basinda ve sikça kullanilmalidir. En kötüsü müsteri
tarafinda kullanilmaya baslayan üründe performans problemlerinin ortaya
çikmasidir ki müsterinin is kaybina neden olur. Performans problemleri
ürününüzde köklü degisikliklere neden olabilir ve önceden teshis çok önemlidir.
Her yeni sürümle beraber bir performans degerlendirme raporuda ürüne
eklenmelidir. Proje adimlarindan bir tanesi de performans da belirli kriterlere
ulasmak olmalidir. Yada bir önceki sürümde ortaya çikan performans degerlerinden
daha iyi bir sonuç elde etmek amaci olmalidir.

Önemli bir not olarak müsterinin veritabanina yükleyecegi veri miktarini iyi
belirlemeniz gerekir. Eger müsteri 1 milyon veri yüklemeyi düsünüyorsa ve siz
performans testlerini 1000 kayit ile yaptiysaniz, bulacaginiz performans
degerleri gerçege yakin olmayacak ve belkide ürününüz müsteri tarafinda
çökecektir.

Klaus Salchner’in NProf makalesinden kismen çeviridir. Kalus’a klaus _ salchner
AT hotmail nokta com adresinden erisebilirsiniz.

Herkese kolay gelsin. Yararli bir çeviri oldugu kanisindayim.

Posted in Bilişim, Türkçe.