Page 17 - MAKSİMUM BİZ | BAHAR 2009

GÖRÜfi
Canl› Kullan›mda gözlemlenen olay Sistem kaynaklar› yetersiz kalm›yordu. Daha aç›k olarak, problem sistemde
fazla bellek oldu¤u için çok fazla
yüklenme yaflan›yordu.
Bafllangݍta performans gayet iyi daha veya kabul edilebilir bir seviyedeydi
5000 simüle edilmifl kullan›c› ile yap›lan testlerde sistemde herhangi bir performans düflüflü gözlenmedi.
Performans tutarl› ve düzenli de¤il
Aç›klama
Uygulama tafl›y›c›lar› belli miktarda sistem kayna¤› harcarlar, buna bellek ve connection pool’lar da dahildir. Tafl›y›c› ile çal›flan bir uygulaman›n ayr›lan sistem kayna¤›ndan daha fazlas›n› kullanmas› mümkün de¤ildir. Fazla sistem belle¤i, tafl›y›c› ile çal›flan bir uygulamaya hiç bir fayda sa¤lamaz.
Bellek kullan›m profili, sisteme fazla kullan›c›n›n dahil edilmesi ile çok belirgin bir flekilde de¤iflti. Zaman geçtikçe bellekte birkaç gün sürelik birikmeler yaflan›yordu. Problem yeni kullan›c›lar›n sisteme dahil edilmesi ile birlikte daha da belirgin bir hale geldi.
fiöyle bir gerçek vard›r ki bu kadar çokkullan›c› ile k›sa süreli testler yap›l›rken bile sistem belle¤i temiz kal›r; fakat sistem yeniden bafllatma yap›lmadan kullan›l›rsa bellek flifle ve periyodik bellek temizli¤i ihtiyac› do¤ar.
• Performans testi sonuçlar›na göre, uygulama- n›n kodu, gerekli sistem kaynaklar› haz›r oldu¤u var- say›ld›¤›nda beklenen performans› destekliyordu.
• Performans düflüklü¤ü devam ediyordu. An- cak bunun zamanla ya da ek banka flubelerinin aç›lma- s› ile nas›l ilgili oldu¤u görülemiyordu.
• Performans düflüklü¤ü önce ara s›ra gerçekle- fliyordu ancak zamanla daha sürekli bir hale geliyordu.
•Performans günün bafl›nda istenilen aral›k- tayd› ancak günün sonunda gittikçe kötülefliyordu.
• Altyap› testleri sonucunda, organizasyon tek bafl›na altyap›n›n hatal› olmad›¤›na karar verdi.
Ön de¤erlendirmelere göre, ekip anahtar uygu- lamalar için J2EE uygulama tafl›y›c›s›n› incelemeye ka- rar verdi. Bunun sonucunda flu sonuçlar ortaya ç›kt›:
Uygulama tafl›y›c›s› (Java virtual machine) -uy- gulama tafl›y›c›s› taraf›ndan gerçeklefltirilen haf›za yö- netimi servisi- bellek temizli¤ini beklenenden daha yüksek bir frekansta düzenliyordu. Her seferinde bel- lek temizli¤i yap›ld›¤›nda bütün ticari ifllemler haf›za yönetimi servisinin ifli bitene kadar duruyordu ve bel- lek temizli¤i ifllemi ortalama 20 saniye al›yordu.
Bu yeni bilgi uyar›nca ekip hatay› buldu¤undan emindi. Gelifltirme tak›m›n›n iflbirli¤i ile birlikte uzman ekip haf›za üzerinde baz› ince ayarlar yaparak organi- zasyonu olmas› gereken hale getirdi.
Herkes teknoloji ekibini çabalar›ndan, uykusuz gecelerden ve sorunu çözmelerinden dolay› tebrik etti. Ancak bir soru belirsiz kald›. Bu olay yaflanmadan önle- nebilir miydi? Bu sorulara cevap verirken, fonksiyonel olmayan tasar›m ve uygulamalar›n planl› bir yaklafl›- m›n ihtiyac›n› görmeye bafllayaca¤›z.
•Canl› kullan›mda gözlenen olaylar›n nas›l aç›klanabilece¤ini yandaki tabloda görebiliriz.
• Peki canl› kullan›ma geçmeden önce, proble- mi daha önceden görmemizi sa¤layabilecek ve test kapsam›nda eksik olan fley neydi? ‹yi bir performans testi kapsam› olmas›na ra¤men, proje tak›m› bütün canl› koflullar›n› simüle etmemiflti. Böylelikle sistemin bu kadar çok kullan›c› ile uzun süreler çal›flma flartla- r› hesaba kat›lmam›flt›. Sürdürülebilirlik testleri, uzun zaman aral›klar›nda, çeflitli yük miktarlar› ile bunlar›n iç uygulama kaynaklar›na ve performansa etkilerini gözlemleyebilmemizi sa¤layacakt›r.
• Acaba bu durum engellenebilir miydi? Cevap tabii ki evet Yukar›da da belirtildi¤i üzere, test uzun zaman aral›klar›nda ve yüksek yük alt›nda sistem tep- kisini gözlemleyebilecek flekilde tasarlanabilir. Her sistem için canl› proseslerine çok benzer bir flekilde simüle edilmifl sürdürülebilirlik testi uygulanmas› önerilmektedir. ‹yi gözlem araçlar› ve kontroller de
Canl› mimarisinde, yük dengeleme için baz› kullan›c› istekleri vard›. E¤er bir sunucu yeniden bafllat›lacak olursa, cevap süresi, bellek temizli¤i yüksek bir frekansta seyir edene kadar, k›sa bir süreli¤ine normale döndürülecekti.
sistemdeki olas› problemler hakk›nda teknoloji ope- rasyon tak›mlar›na bir ön uyar›c› olacakt›r.
Bu durumda, yeterli seviyede gözlem ve bellek yönetimi ile teknoloji operasyon tak›m›, periyodik bel- lek temizli¤inin gereklili¤ini görebilirdi. Böylelikle 20- 30 saniyelik sistem cevap süreleri de bu seviyelere varmadan çözülebilirdi.
Yukar›daki vaka güçlü bir planlama ve yeterli testlerin kritik sistemler için ne denli gerekli oldu¤unu göstermektedir.
Çeviri: Patterns for Performance and Operabi- lity: Building and Testing Enterprise Software By Chris Ford, Ido Gileadi and Mike Moerman
TAHS‹N ERDO⁄AN
Genel Müdür Yard›mc›s›
‘’Sonucu mant›ksal bir yap›ya ba¤l› olsa da yenilikçilik mant›kl› düflüncenin ürünü de¤ildir. ‘’ Albert EINSTEIN
15