JConsole ile Performans Gözlem - Part 2

JConsole'un en önemli ve en kullanışlı tablarından birisi Memory tabı.. Memory'nin grafiği size durumun nasıl gittiğini anlatır. Neler olabileceğine dair fikirler verir. Figure 3'te gördüğünüz grafik sıradan bir Heap Memory'nin yaklaşık yarım saatlik süreçteki akışını göstermektedir. Grafiğin hemen altında yeşil renkle gördüğünüz sütunlar, değişik memory kısımlarını göstermektedir. Sırasıyla Survivor Space, Young Space, Old Space, Permanent Space, Code Cache Space'tir. Altlarındaki yatay çubuklar ise üzerlerindeki sütunların toplamlarını göstermektedir. Eğer JVM tune ediyorsanız, bu parçalar hakkında bilgili olmanızda fayda olacaktır. Bu parçalar hakkında yüzeysel birer açıklama yapayım.
Survivor Space : Swap Space gibidir, hafıza içerisinde yeri değiştirilecek nesneler için kullanılır.
Young Space : Hafızada süre olarak yeni olan objelerin tutulduğu yerdir. Minor GC bu kısımda yapılır.
Old Space : Göreceli olarak hafızada daha uzun süre yer alan nesneler burada tutulurlar. Major GC dediğimiz ve yapıldığı sürede JVM'in başka birşey yapamadığı Garbage Collection burada yapılır.
Permanent Space ve Code Cache Space : Bu kısımlar JVM için ayrılan yerin dışında yer kaplarlar ve mesela statik yüklenen class'lar burada tutulur.
Bu kısımların nasıl efektif kullanılacağı ile ilgili bilgileri
Tuning the Java Runtime System
tagtraum industries
A Collection of JVM options
linklerinde bulabilirsiniz.

Bu bilgilerin yanında kolonlara tıkladığınızda o kolonlarla ilgili bilgileri JConsole'u çalıştırdıktan sonra geçen zamana ait olarak görebilirsiniz. GC Time kısmında kaç kere Major GC (Yukarıdaki) yapıldığı ve ne kadar sürdüğü ve kaç kere Minor GC (Aşağıdaki) yapıldığı ve ne kadar sürdüğü görülebilir. GC'nin ne olduğu, nasıl izlendiği ile ilgili arkadaşım ve meslektaşım Mustafa Tan'ın Java Hafıza Problemleri ve GCViewer yazısı iyi bir kaynak olabilir.

Figure 3

Threads tabı bir diğer hayat kurtaran tabdır. Yani en azından bizim için öyle olmuştur. Figure 4'te gördüğünüz ekranlarda JVM içerisinde yer alan thread listesini ve bunun tomcat ile ilgili olan (yani web servlet aracılığı ile gelen) thread listesini görebilirsiniz. Aşağıdaki filter kısmına thread ile ilgili belirleyici bir kaç harf giriyorsunuz ve ta-tam, thread'leriniz listeleniyor. Bundan sonra yapmanız gereken sadece hangi threadin detayını görmek istiyorsanız ona tıklamak. Eh artık biraz da stack trace'den neler çıkarabileceğimize kalıyor iş.

Figure 4

MBean'ler ve invocation'ları ile ilgili bilgileri Figure 5'teki MBeans tabında bulabilirsiniz. Bu tab içerisinde soldaki navigasyonda erişebildiğiniz mbean'leri ve bu mbean'lerin metodlarını bulabilirsiniz. Eğer az çok JBoss'un JMX console'una aşina iseniz, bu ekran sizin için hayli güzel şeyler içerebilir. Ben örnek olarak Threading'i seçtim. e

Figure 5

Son tabımız ise Figure 6'da da gördüğünüz gibi VM tabı, biraz summary tabına benzesede burada bulacağınız bilgiler de gayet kullanışlı olacaktır. Bu bilgiler sırasıyla, JVM'in hangi Java versiyonu ile çalıştığı bilgisi, çalışan JVM'in process numarası (name kısmında @ işaretinden hemen önce), kullandığınız JVM argümanlarının tam bir listesi, çalışan JVM'in classpath'i boot classpath'i gibi faydalı bilgiler bazı diğer makine konfigürasyonu bilgileridir.

Figure 6

Bu yazıya ek olarak belirtmekte fayda göreceğim birkaç nokta var. JDK 6.0 ile birlikte gelen JConsole içerisinde JVM'in makine üzerinde yarattığı CPU yükünü takib edebiliyorsunuz. Yani yeni bir özellik olarak CPU izleyebilme eklenmiş. Summary tabı ile VM tabı birleştirilmiş. Bunun yerine ilk açtığınızda karşınıza Memory, Threads, CPU ve Classloading'den oluşan dörtlü basit bir monitor geliyor. Hmm bir de JDK 6.0 üzerindeki JConsole'a yazılmış birkaç tane eklenti gördüm. JDK 5.0'daki JConsole'da yoktu, ya da ben rastlamadım.

Bu kadar kolay ve rahat kullanılabilen bir aracın neler yapabildiğini anlatmaya çalıştım. Bu durumda şunu söyleyebilirim, ne şekilde olursa olsun, sistemleri gözlemlemek, hem sistemin doğasını anlamanıza yardımcı olur, hem de sistemi mevcut durumundan daha iyi bir düzeye getirmek için elinizde bulgular olmasını sağlar.

JConsole ile Performans Gözlem - Part 1

Performans Gözlemlemek sistemler için vazgeçilmez bir kavramdır. Bir sistemde oluşan sorunlar kadar, oluşabilecek sorunları önceden tahmin edebilmek de hayati bir aksiyondur. Sorun oluştuğu esnada sistemin parametrelerini gözlemleyebilmek ve sorunun sebebini bulmak hayat bile kurtarabilir.

İşte JConsole, eğer java tabanlı uygulamalar geliştiriyorsanız, işinize yarayacak güzel bir araç. En büyük özelliği JDK (5.0 ve sonrası) ile birlikte bedava geliyor olmasına rağmen boyundan büyük işler yapıyor olması. Geliştirdiğimiz projede yaklaşık 1 yıldır JConsole'dan faydalanıyoruz. Kullanımı çok basit, ama söylediğim gibi yaptıkları çok büyük.

Avantajları ve Dezavantajları

• En büyük avantajı, izlenilmek istenilen sistemler üzerine yük getirmiyor olması. Performans gözlem araçları, genellikle, izlenilmek istenen uygulamanın yanına bir agent kurarlar. Bu agent aracılığı ile merkezi bir server'a bilgi gönderirler. Ve izlenilen uygulamaya yük getirir.
• Bir diğer avantajı, kurulumunun ve hayata geçirilmesinin çok kolay olmasıdır.
• Bunun dışında belli bir süre gözlemledikten sonra (yaklaşık 7-8 saat) merkezi izlemenin yapıldığı sistemde (Genellikle PC olur bu) performans sıkıntısı yaratabilir.
• Verdiği bilgiler, çok detaylı bilgiler değildir. Yani memory ve cpu (JDK 6 ile birlikte) gözlemlenebilir, ama response time ve throughput değerleri gözlemlenemez (en azından eklentiler olmadan).
• JDK 6.0'dan sonra JConsole'a eklenti yazılabilme esnekliği getirilmiştir.

Bu avantaj ve dezavantajlar daha detaylandırılabilir.

JBoss üzerine nasıl JConsole'un yerleştirilebileceğini ve gözlemlediğimiz bilgilerin ne anlama geleceğini aşağıda anlatmaya çalışacağım.

Kurulumu ve Çalıştırılması

1. JVM argument'larının java satırına eklenmesi

Öncelikle, java ile çalıştırılan komuta bazı eklentiler yapmamız gerekiyor. Bunun için run.sh içerisinde JAVA_OPTS değişkenini bulup bunun sonuna

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

attribute'larını eklememiz gerekiyor. Bu attribute'lardan bizi ilgilendiren ve ileride kullanacağımız jmxremote.port, yani 9000.. Bu, merkezi açtığımız jconsole'un remote olarak bağlanacağı makinenin hangi porttan bilgileri vereceğini gösteriyor. Sonra tabi ki sunucuyu restart etmemiz gerekiyor. Açılırken herhangi birşey yüklemiyor. Bu konuda kafanız rahat olsun, sadece verdiğimiz porttan JConsole isteklerini dinleyip, bunlara response verecek.

2. Local'den JConsole'un çalıştırılıp remote sunucuya bağlanması

${JDK5_HOME}/bin altında jconsole.exe var. Bunu çalıştırıyoruz ve bitti, evet bu kadar. Ne kurulum yaptık, ne de konfigürasyon ayarladık. Dediğim kadar basitmiş değil mi? Karşımıza aşağıdaki Figure 1'deki ekran geliyor. Host or IP kısmına incelemek istediğimiz IP'yi, port kısmına jmxremote.port attribute'unda verdiğimiz port numarasını yazıyoruz...

Figure 1

Login işlemi sona erdiğinde önünüze gelen Figure 2'deki ekranda JVM ile ilgili genel bilgileri görebilirsiniz. Bu ekranda en çok kullandıklarımı ve zaman zaman sorun çıktığında başvurduğum bilgileri aşağıda kısaca açıklamaya çalışacağım.

Uptime = Server'ın ne kadar süredir çalıştığını gösterir. Bunu availability ile ilgili birilerine birşeyler kanıtlamam gerektiğinde kullanırım. Mesela bu ekranda server'ın yaklaşık 6 gündür ayakta olduğu görünüyor.
LiveThreads = JVM içerisindeki aktif thread sayısını görürsünüz. Bu sayı sistemin çalışması esnasında belli bir sayı aralığında dolaşır. mesela 60-90 arasında. Ama bunun üzerine çıkmaya başlarsa sistemde bir sorun başgösteriyor olabilir.
Memory ve classes için ayrı bir tab mevcut dolayısıyla bundan sonra bahsedeceğim, fakat JVM instance'ının üzerinde çalıştığı makinenin fiziksel memory'si ile ilgili birkaç bilgiyi Operating System kısmında bulabilirsiniz.

Figure 2

Bir sonraki yazımda JConsole ile memory grafiklerinin takibi, JVM thread'lerinin incelenmesi, Remote MBean Invocation ve JVM ile ilgili diğer bilgilere nasıl ulaşacağımızı, bunların yanında bunların nasıl kullanılırsa hayat kurtarabileceğini anlatmaya çalışacağım.

Developer sadece kod mu yazar?

Bundan 7-8 sene önce Kıbrıs'ta bir grup arkadaş program yazdığımız sırada, ya da ondan bir kaç sene sonra yine bir grup arkadaş, İsrail'e bir proje geliştirdiğimiz sırada, yaptığımız tekşey kodlama idi. Yani, kodumuzun nasıl çalıştığı, nerede çalıştığı ile ilgilenmez, sadece ne yaptığı ile ilgilenirdik. Sonra okul bitti ve şimdiki işyerimde çalışmaya başladım. Burada bir iş akış sistemi geliştiriyorduk. Burada da kod yazıyorduk, ama zaman zaman IIS'i restart etmemiz gerekiyordu. Sonra, kodumuzda bir açık olduğunu ve sistem performansında darboğaz oluştuğunu farkettik, bu sefer yavaş yavaş yazılan SQL cümlelerini analiz etmeye başladık. Sonra MS SQL Server üzerinde Performance Tuning olayları ile ilgilenmeye başladım. Bu bahsettiğim olay ise tam 3 sene önce idi.

Yukarıda kendi programcılık deneyimim ile ilgili yazdığım paragraf bile, bir developer'ın on senelik sürede nasıl değiştiğini, nasıl değişmesi gerektiğini sanırım ifade etmiştir. Yani bundan 10 sene öncesinde bir developer sadece kod yazıyordu, ama aradan geçen zaman ve proje yönetimi kavramındaki pozitif değişiklikler beraberinde Agile Development ve Extreme Programming kavramlarını getirdi. Ve bu kavramlar da developer'ın yapması gereken işleri ve sorumluluğunun çerçevesini genişletti.

Şimdi birazda şu anda geliştirilen uygulamalara bakalım. Örneğimiz de benim üzerinde çalıştığım proje olsun. Kapsamlı ya o bakımdan.. Geliştirdiğimiz projede developer'lardan ilk beklentimiz darboğaza yol açmayacak kodları sürüm sistemine dahil etmeleridir. Bunu yapmak için developer'lar (isterlerse 3rd party tool'lar kullanarak) kodlarını analiz edip, olası bug'ları ve leak'leri temizlemek zorundadırlar. Bu da onlara kod yazmanın yanında kodlarını analiz etme yükümlülüğünü de getirmiştir. Sürüme katılan her bileşen veritabanı ile ilgili yaptığı operasyonlardan sorumludur, mesela bir tablo yaratılacaksa, uygun index'ler ile yaratılmalı ve gerekli key'ler verilmelidir. Bu da veritabanı bilgisi ve performans iyileştirme kavramlarını getirmektedir. Kodlama içerisinde bir SQL cümleciği sorun yaratıyorsa, bunu TOAD veya SQL Navigator'da açıp SQL'in nerede takıldığını bulmak zorunda olabilir, bu da yine performans iyileştirme kavramını beraberinde getirmektedir. Büyük ölçekli sistemlerde çıkabilecek hataları önceden tahmin etmek için kodlarını lokalde çalıştırıp Memory ve CPU değerlerini gözlemlemelidir, bunun içinde etrafta bir sürü araç mevcut. Sakın gözünüz korkmasın, bu bahsettiğim işler yapılan işler. Yani çalıştığım projede zaman zaman bu tür voltranlar oluyor. Arada sırada ışın kılıcını falan çıkarıyorlar.

Evet Voltran, bundan sonra developer değil Voltran diyeceğim. Çünkü yazdıklarımdan sonra Developer kavramı Voltran'a benzedi değil mi? Ama doğal eleksiyon sadece doğada yok, iş piyasasında da var. Yani bunları yapabilen developer'ın yaşama şansı daha yüksek.. Çünkü bu tür yeteneklere sahip developerlar geliştirilen projeye daha çok katkıda bulunurlar. Yani bir programlama dilinde mükemmel kod yazıyor olabilirsiniz, ama artık sadece mükemmel kodlama yapmanın yanında yazdığınız kodun sistem ile entegrasyonunu anlamak, iş mantığını çözmek ve sistemi bir bütün olarak düşünebilmek yavaş yavaş ağır basmaya başladı.

Developers' Changing Roles linkinde bulduğum bir röportaj bayaa ilgimi çekti. Can alıcı ve hakikaten gözümüzün önünde olduğu halde, bize sıradan gelen bir değişimin hikayesi..

Performans Gözlemin Önemi

Çalışan uygulamaların ve uygulama sunucularının sürekli gözlemlenmesi gerekir. Sorunun ne zaman ve nereden geleceğini bilemeyiz, eğer biliyorsak sorun bizdedir, bu durumda "tembel ne duruyorsun? madem sorunu biliyorsun, çözsene!!!" derler, demezler mi?!?

J2EE uygulamalarının üzerinde çalıştıkları Uygulama Sunucuları, birçok özellikleri ile bu tür dikizlenmeye (monitor edilebilmenin argosu) müsaittirler. Birçok uygulama sunucusu kendi üzerinde MBean'lere sahiptir ve bu MBean'lerin remote çağrılması ile kendilerine ait bazı bilgileri çağırana iletir. Etrafımızda Uygulama Sunucusu izleme için birçok araç vardır. JConsole, JBoss ON, Tivoli ITCam, Hyperic, Applications Manager, JProfiler gibi. Bunların hepsini bilmenize veya kullanmanıza imkan yok. Ama hepsi ile ilgili kısa birer açıklama faydalı olacaktır.

JBoss ON - Uzunca hali JBoss Operation Network, adından belli JBoss için yapılmış olan bu uygulama JBoss'un CPU bazında lisans ücreti talep ettiği bir uygulama. Sadece performans monitoring değil, aynı zamanda uygulama sunucusu yönetimi de sağlıyor. Hepsi bir arada, fiyatı 30 CPU ve fazlası için yanlış hatırlamıyorsam 80,000 € civarındaydı.

JProfiler - İşte JVM'in process'ine yapışıp, hayatını sömüren uygulamalardan birisi. Sistemde acaip bir yük yaratıyor. Çok kullanışlı bulmadım. En son 5.0 versiyonunda birçok düzeltme olduğunu duydum.

Hyperic - Durum biraz daha kaliteli hale geliyor. Linux'te kendi kullanıcısını yaratıyor, Database'de şema istiyor. Ama hala yeterli değil.

Applications Manager - Kurulumu ve kullanımı çok kolay, 5 sistemi ücretsiz monitor edebiliyorsunuz, ama fazlası için para ödemeniz gerekiyor. Local'inize kuruyorsunuz, servisi başlatıyorsunuz, istediğiniz sistemi monitor edebiliyorsunuz (JBoss, Tomcat, Oracle ve hatta Linux)

JConsole - Yaklaşık 1 senedir kullanıyorum, neredeyse tüm sorunlarımı çözebiliyorum, memory leak'leri, bu leak'lere yol açan thread'leri bulabiliyorsunuz, JDK ile birlikte geliyor, sisteme yük getirmiyor. JConsole ile ilgili detaylı bir guideline ve gerçek hayat uygulamasını avantajlarını ve dezavantajlarını daha sonraki yazılarımda yazacağım.

Tivoli ITCam - Bu da IBM'in WAS'ları dikizlemek, ve üzerlerinde tam hakimiyet kurup sorunları tespit etmek için kullandığı bir ürün. 2004'te IBM ailesine katılmış. Tivoli başlı başına bir gözlem canavarı, ama bizi sadece ITCam ilgilendiriyor. Bunun kurulumunu yaptık, bununla ilgili de gözlemlerimi ilerleyen yazılarımda paylaşacağım.

Farkındaysanız, çalışan uygulamaların ve uygulama sunucularını gözlemlemek ne kadar önemli, ne kadar hassas yapılması gereken ve ne kadar sorun çözen bir işlem. Tabi memory, CPU gözlemlemek, hani derler ya "Ağaç yaşken eğilir", o hesapta taa Development'tan başlatılabiliyor. Bunun için de çeşitli IDE plugin'leri mevcut. Yukarıda listesini verdiğim gözlem araçlarının dışında tonla gözlem aracı mevcut, ben sadece deneyim yaşadıklarımı veya en azından duyduklarımı yazıyorum.

Gant (Groovy Ant)

Çoğu sürüm sisteminin temelini Ant scriptleri oluşturur. Ant scriptlerinin üzerine CI (Continuous Integration) Server'lar yerleştirilir. Otomatik ve manuel çalıştırılan scriptler ile hayat daha da güzelleştirilir. Ama benim gibi programcılık kökenli iseniz, Sürüm Sistemi'nin her katmanını sorgulayıp, "daha programlanabilir veya daha esnek olamaz mıydı?" diye sorabilirsiniz.

Gant ise bu noktada kısmen düşüncelerimize yanıt verecek bir yapı sağlıyor. Kısmen dememin sebebi ise Gant'ın Ant'a değil, Ant scriptlerini yazma şekline bir alternatif olması. Gant, Groovy script'den başka birşey değil. Ama Ant gibi XML'in kısıtlamaları ile çevrili değil. Yazdığınız bir target içerisinde diğer target'ları aynı kodlama yapıyormuş gibi birer altmetod olarak çalıştırabiliyorsunuz.

target ( altmetod : 'Aciklama alani' ) {
Ant.echo ( message : 'altmetod calisti' )
}
target ( metod : 'Aciklama alani' ) {
altmetod ( )
Ant.echo ( message : 'metod calisti' )
}

Uzun süredir, ant scriptleri ile çalışıyorsanız, yukarıdaki gibi ant scriptleri yazabilmenin yanında neleri yapabilmeyi getirebileceğini hayal edebilirsiniz. Bu arada Gant'ın tüm Ant Core Task'larını desteklediğini söylemekte fayda var. Kullanması çok basit, "Ant." deyip, ardından task'ın adını yazıyorsunuz, attribute'ları da yukarıdaki formatta "attr_name : value" şeklinde verebiliyorsunuz.

Gant'ın dezavantajlarından birisi Groovy öğrenmenizin gerekmesi, bir diğeri henüz yeni olduğu için tüm CI Server'lar ile çalışamıyor olması (mesela Hudson, ama CruiseControl'a bakmadım).

Ama Gant ile birlikte kimbilir belki birgün Java'da bir scripting dili ile Ant'a yardımcı-rakip olmaya çalışır.

Websphere, Weblogic, JBoss - Part 2

Altyapı değişikliği çok hassas karar verilmesi gereken bir konudur. "Gelen gideni aratır"sa altyapı değişikliğinin pek bir anlamı olmaz. Dolayısıyla, öncelikle ideal bir topoloji düşünülmeli, ardından yeni altyapının bu topolojiyi destekleyip desteklemediği araştırılmalıdır.

Peki bizim sistem olarak yeni altyapı ile ne gibi avantajlarımız olacak?


Support and Documentation

Eğer alınan ürün için lisans ücreti ödeniyorsa, en az 1 yıllık bakım ve destek anlaşması da yanında gelir. Dolayısıyla doküman ve destek ile ilgili sıkıntılarımızda karşımızda bir muhattap olması her zaman bir avantaj olarak değerlendirilir. Mesela, Open Source dünyasında para eden kısım budur. Düşünün ki, bir akşam sistemin bir sorunu ile uğraşırken yalnız olmayacaksınız. Sizinle birlikte kafa patlatan başka biri daha olacak ve bu kişinin size o konuyla ilgili yardım etmek gibi bir sorumluluğu olacak. Biraz tembelce, ama 7/24 sistemler için çok önemli bir konu.

References

Bir ürün alırken aslında en önemli konu referanslardır. O ürün daha önce kimler tarafından kullanılmış? Acaba bizimle aynı şekilde mi kullanmışlar? Ne kadar uzun süredir kullanıyorlar? Bu referansların en önemli avantajı, karşılaşabileceğimiz herhangi bir problem, eğer daha önce aynı ürünü kullanan başka bir firmaya sorun çıkarmışsa ve çözülmüşse; bizim sorunumuz da aynı yöntemlerle daha kısa zamanda çözülebilir. Dolayısıyla Amerika zaten keşfedildi, yeniden keşfetmeye çalışmanın bir alemi yok.

Product Family

Her ne kadar open source dünyasını sevsem, implementasyon olayına bayılsam da, şunu unutmamak lazım ürün ailesi kavramında her zaman için aile üyeleri birbirleriyle iyi anlaşırlar. Yani aldığınız ürün bir ürün ailesi ise daha önce yaşanılan sorunlardan ve problemlerden dolayı muhakkak beraber daha performanslı ve daha iyi yaşamak ve çalışmak için optimize edilmişlerdir. Düşünsenize, elinizin altında bir JVM ve bu JVM'i monitor etmeye yarayan bir araç var. Ve siz, bu entegrasyon için endişe etmiyorsunuz, çünkü zaten bu ikisi birbirine entegre olabilsin diye optimize edilmiş, bunun yanında belki binlerce kez de entegre edilmiş. Yani siz bunu yapmaya çalışan ilk araştırmacılardan biri olmayacaksınız.

Bunların dışında gruplayamadığım bir sürü avantaj var. Bunları da yıllardır her bir bileşene ayrı ayrı kafa yorduğum için biliyorum.


Bütün bu değerlendirmeler ışığında son olarak yapılması gereken yük ve performans testi değerlendirmesidir. Bu da en güzel kendi uygulamalarınızla yapılır.

Ben de üç ayrı uygulama sunucusunu (JBoss 4.0.5, Websphere 6.0, Weblogic 9.1), iki ayrı makine/işletim sistemi konfigürasyonunda (AIX 5.3L-IBM, Solaris 9-Sun) iki ayrı senaryo ile test ettim. Testi IBM Rational Performance Tester kullanarak yaptım. Herbir sunucuyu kendi bilgi birikimim ile tune etmeye çalıştım. Testleri yaparken, 5, 20 ve 50 eş zamanlı kullanıcı ile yük yarattım. Çıkan sonuçlar ilgi çekici idi. Özellikle JBoss'un gösterdiği performans gayet ilgi çekici ve başarılı oldu. Tabi içimden keşke bu versiyon ile Distributed Transaction desteği tam olsaydı dedim.

Uzun lafın kısası biz sistem olarak karşılaştırmayı yaparken, uygulama mimarisini de işin içine kattık, performans testinden çıkan sonuçlar sadece kararın bir ayağını oluşturuyor. Kararı vermeniz için uzun vadede tüm ayrıntıları göz önüne almanız gerekir.

Ant Utility (Ant yardımcısı)

Ant scriptleri, neredeyse tüm sürüm sistemlerinin temelini oluşturuyor. Her tür J2EE projesi ant scriptleri yardımı ile sahne alıyorlar. Buna rağmen ant ile ilgili hergün yeni birşeyler öğrenme fırsatımız oluyor. Ant Utility de bu yeni örneklerden birisi (en azından benim için). Bize ne faydası var? Eğer uzun ant scriptleriniz varsa ve bunların çalışma süreleri ile ilgili sıkıntıların varsa; aşağıdaki yolu izleyerek Ant Utility'yi devreye alıp, her target'ın içerisindeki her task'ın ne kadar sürede bittiğini görebilir, ve gerekirse bunlar üzerinde çalışabilirsiniz.

Yapmanız gerekenler çok basit,
1 - Ant Utility web sayfasına girip antutility.jar'ı indirin,
2 - Bu jar'ı ant lib'in altına atın
3 - ant komutunun hemen yanına "-listener net.java.antutility.BuildMetricsListener" ifadesini ekleyin

Sonuçta ekrana aldığınız çıktının sonunda BUILD METRICS diye yeni bir kısım göreceksiniz, burada tasklar ve target'lar çalışma sürelerine göre sıraya sokulmuş bir halde yer alacak. Ee bundan sonrası çok basit tabi, text virgüllerle ayrılmış. Açıp excel'i içerisine import edeceğiz.

Bu arada Ant Utility open source dolayısıyla download edip, çıkaracağı output'un formatı ve hatta değerlerini bile değiştirebilirsiniz. Topu topu dört tane java dosyası var.

Websphere, Weblogic, JBoss - Part 1

Altyapı değişikliği yapmak, hem de uzun bir süreden sonra, hem de çok kapsamlı. Acaip riskli bir iş, riskli olduğu kadar zevkli de. Neden zevkli, çünkü her zaman göremeyeceğin şeyleri görme fırsatın oluyor. Ve yeni şeyler öğreniyorsun. Neyse bizim şirkette de bu tür bir çalışma yapılıyor..

Altyapı değişikliği yapmamızın sebeplerinin başında mevcut sistemin yetersizliklileri ve düşünülen ideal yapının getireceği avantajlar var. Bu seride sırasıyla mevcut sistemin dezavantajları, düşünülen sistemin avantajları, ve bu sistemlerle ilgili karşılaştırma yorumlarımı yazacağım.

Kısaca Mevcut yapı : JBoss ve Weblogic ortak kullanılıyor. Ürün ortamında yaklaşık 12 tane JBoss instance'ı ve 7 tane Weblogic instance'ı var. JBoss instance'larının her biri yaklaşık 3 GB, Weblogic'ler ise 2 GB JVM ile çalışıyorlar.

Support and Documentation

Yetersizliklerin en başında JBoss'un open source olmasından dolayı, sorunla karşılaştığımızda buna müdahele ederken kaynak ve destek konusunda çektiğimiz sıkıntılar geliyor. Bunu da şu şekilde anlatayım.

Şanslıysam, daha önce birisi daha JBoss'ta aynı problemle karşılaşmıştır.
Daha şanlıysam, bu problemini internette forumlarda paylaşmıştır.
Daha daha şanslıysam, bu problemi çözmüştür.
Hepten şanslıysam, çözümü internette biryerlere yazmıştır.

Yani nasıl bir şansa ihtiyacım olduğunu siz düşünün. Bu durum bana hatırı sayılır bir deneyim kazandırdı, bunu inkar edemem. Ama bunun yanında eğer bir sistem 7/24 çalışmak zorunda ise ve size kalan mini minnacık kısıtlı zamanda bu tür bir araştırma yapmanız gerekirse, sanırım yeterince terlersiniz. Projemiz henüz bu aşamada değil, ama çok yakın bir zamanda 7/24 çalışması gereken bir sistem haline gelecek. Bu da sorunlara müdahele şeklimizi değiştirmemizi gerektirecek.


Scalability

Ölçeklenebilirlik, aslında bizlere mühendislik eğitiminde neredeyse sürekli anlatılan bir kavramdır. Ama nedense iş pratiğe geldiğinde günü kurtarma adına verilen kararlar, hem ölçeklenemeyebilirlik yaratmakta, hem de ileride çözümü çok çok zor olan sorunlara yol açmaktadır. Ölçeklema kavramında işin büyük kısmı tasarım ve geliştirmeye düşse de, uygulama sunucusunun da ölçek büyüdükçe buna dayanabilmesi gerekmektedir. Ve hatta daha iyi performans gösterebilmesi gerekmektedir.

Her ne kadar sorunlarla karşılaştığımızda sistemlerimizi dikey veya yatay olarak büyütsek de, buna ihtiyacımızı en aza indirebilmek uygulama sunucusunun görevlerinden biridir. Yaa düşünsenize gerçek hayatta ayakkabı alırken dahi, "bir numara büyüğünü al, gelecek sene de giyersin" diyen bizler, her zaman proje geliştirirken proje büyüklüğünün bu şekilde kalacağını düşünürüz. Ne ironi ama.


Performance Monitoring

Yaşadığımız sıkıntılar içerisinde ilk sıraları zorlayan ve zaman zaman birinciliği alan sorunlardan bir tanesi de, sistem üzerinde performans gözlemleme işlemini layığıyla yapamamızdı. Aşağıda bu sistemde kullandığımız 3rd party tool'ları sıralayayım.

JProfiler - Ürün ortamında kullanmak neredeyse imkansız, sisteme getirdiği yük hayli fazla, dolayısıyla kullanmak istiyorsan, Alfa veya Beta ortamlarında kullanabilirsin ki onu da denedim, o bile işkence idi.

GC.log - JVM içerisine birkaç parametre yazdığınızda sistem Garbage Collection ile ilgili tüm dataları bir dosyaya yazıyor, ve server'ın yaşam süresi boyunca bu dosyayı güncelliyor. Aman dikkat dosyayı yanlışlıkla silerseniz yeniden yaratmıyor. Taa ki sunucu restart olana kadar. Bundan sonrası ile ilgili iyi bir Konfigürasyon Yöneticisi arkadaşımın yazılarında detaylı bilgi var java hafıza problemleri ve GCViewer

JConsole - Neredeyse aralarında favorim budur. Ne ortamlara yük getiriyor, ne de bir sürü ayar yapmanız gerekiyor. Sadece JVM'e birkaç parametre yazıyorsunuz, bitti. Ama bu bile sistemde sadece memory'yi takip etmemize, mevcut thread'leri izlememize yarıyor, ve bundan öteye gidemiyordu.

TomcatListener - Bunu da ben yazdım. Aurora ve JBoss kullanıyorsanız, gayet kullanışlı...

Bu listeden sonra bile, yine de sistemde bir sıkıntı olduğunda bu sıkıntıyı bulmak, bulamadığımız durumlarda geçici çözüm üretmek yeterince zor oluyor. Bu durumda son çare olarak uygulama sunucusunu restart ediyoruz. Yine aynı noktaya geliyoruz, sistem çok yoğun çalışmadığı durumlarda bunu yapabiliyoruz, ama yarın sistem 7/24 çalıştığı zaman bizden hesap sormazlar mı?