JVM tuning

Alelade Hikayeler – II: Bir Başka Performans Problemi

Hikayeler, Java, Performans , ,

Bugünkü hikayemizde yine bir performans problemi var. Problem, Java EE ile geliştirilmiş ve Weblogic AS üzerinde çalışan, transactional, web üzerinden tamamen internete açık ve sorgulama arayüzlerinin yoğun olarak kullanıldığı bir bilgi sistemiydi. Sistem çoğunlukla mesai saatleri içinde kullanılıyordu, sonrasında erişilebilir olsa bile kullanımı çok azdı. Problem ise, tamamen gelişigüzel ya da random olarak seyreden yavaşlıktı. Sistem yöneticileri yaptıkları gözlemlerde zaman zaman, ön taraftaki use caselerle ilişkilendiremedikleri yavaşlamaların sebebinin aşırı bellek tüketimi olduğunu belirlemiş durumdaydılar. Sistem clustered bir ortamda çalıştığından herhangi bir kesinti yaşanmıyordu ama bu problemin de çözülmesi gerekliydi.

Sistem yöneticilerinin verdikleri bilgilerden sonra lider developerlarla görüştüğümde, bazı usual suspect araştırmalarımı yaptım. Örneğin veri tabanı sorgulamaları, sorgulardan dönen verinin mahiyeti, bu verinin uygulama tarafından nesnelerle nasıl yönetildiği, web tarafındaki oturum (session) yönetimi vs. konulardaki yaklaşımlarını öğrenmeye çalıştım. Developerlardan bir şey çıkmadı, dahası her şeyi düşünerek ve iyi bir şekilde yaptıklarını, bundan dolayı da bu bellek problemine anlam veremediklerini söylediler. Biraz da “bizim problemimiz” değil havasındaydılar izlenimi elde ettim.

Sonrasında, sistemin kullanımda olmadığı, gece yarısı gibi bir zamanda, canlı ortamdaki uygulama sunucularının bize daha fazla bilgi verecek şekilde çalıştırılmalarını sağladım. Ben de test amaçlı kullanılan, pre-production sistem üzerinde çalışmaya başladım. Ortama girmek, genel de olsa mimariyi öğrenmek, sistemin ayağa kalkarken kullandığı parametrelerini bulmak vs. nihayetinde böyle ortamlarda sıklıkla yaptıklarımdandır. Sistemler büyüdükçe, onlara dokunmak ve bilgi almak daha da karmaşıklaşır. Erişebilmek bile bir problem haline gelir.

Neyse, test sistemi üzerinde bunları elde ettikten sonra, olabildiğince çok kişinin, sistemi kullanması sağlandı ve ben de JVM içindeki olup biteni gözlemlemeye başladım. Fakat bu çalışma çok da işe yaramadı, çünkü problemli durumu üretmedi. Sebebi, kullanıcı sayısını azlığı yanında, hep bildiğimiz, developerların tester olarak kullanılmasının getirdiği yapaylıktı. Fakat sebebini bilmediğimiz bir problemi ararken, şansımızı olabildiğince arttırmak için yapılabilecek her şeyi yapma eğiliminde oluruz. Hatta bu çalışmalar sırasında, performansla pek de alakası olmayan konularda gözlemler yaptım ve bunları paylaştım. Mesela isimlendirme ile ilgili konulardan tutun da çok karmaşık metot ve sınıflara kadar, cohesion ve coupling problemleri, gerekli gereksiz kullanılmış wrapper sınıflar, çok threadli ortam olmasına rağmen bu göz önüne alınmadan yazılmış kodlar vs. Tonla teknik borç çıkar o sıradaki çalışmalardan ama bunları kim duyar da kulak verir, onu sormayın.

Performans problemlerinin sebebini bulmak çoğu zaman onları düzeltmekten daha zor olabilir. Çok basit bir kod hatası, deadlock ya da sonsuz döngü problemi, hemen hiç bir şekilde koda bakarak anlaşılacak tipten bir problem değildir örneğin. Dolayısıyla o hatayı tekrardan üretemezseniz, probleme yol açan durumu tekrar, kontrollü bir şekilde gözlemleyemezseniz, problemi bulmak için çok da şansınız yoktur. Zamanınız ve imkanınız varsa, sistem üzerinde otomatik test araçlarıyla çalışıp yük üretebilirsiniz ama hala problemi oluşturacak durumu yaratamayabilirsiniz. Örneğin, yüzlerce arayüzün belki de çok basit bir noktasından tetiklenen bir problemdir peşinde koştuğunuz ama siz boş yere farklı use caselere yüklenerek arka tarafta, JVM’in içinde bir bellek problemi, çok uzun süren metot çağrıları, veri tabanından dönmeyen sorgular vs. arar durusunuz. Nitekim burada da öyle oldu.

Ertesi gün çalışmaya devam ederken, canlı ortamdaki uygulama sunucularından birinde benzer bir yavaşlık gözlemlendi ve sonrasında uygulama sunucusunun JVM’inin dumpını alıp üzerinde çalıştığımda, hiç bir filtreden geçmeden dolayısıyla “where” ifadesine sahip olmadan veri tabanına gönderilen bir sorgunun, yüzbinlerce satırı belleğe yüklediğini, JVM’in de heap belleğinin tamamını bu sorgudan dönen satırlardaki nesneleri oluşturmak için kullandığını gözlemledim. Hatta dumptan yola çıkarak o anda sistemde hangi kullanıcıların oturumlarının olduğunu, hangi kullanıcının, web arayüzünde nerede, bu sorguyu çalıştıracak use casei işlettiği vb. verilerin hepsine ulaştım. Bu arada parantezlik ufak bir bilgi: Eğer kritik bilgileri, örneğin şifreleri vs. hashlemezseniz, benim gibi çalışanlar, o anda sistemi kullananların tüm mahrem bilgilerini kolayca görebilirler!

Sonrası iplik söküğü gibi geldi zaten. Ön tarafta, arayüzde ne yapıldığı, arkada hangi metot çağrılarından sonra veri tabanına hangi sql cümlesinin gönderildiği, dönen cevaptaki satır sayısı, her satırdaki bilgi vs. hepsini ortaya koydum. Developerların gözünden kaçan bir durum, kötü bir sql sorgusu oluşturuyor ve joinlerden sonra oluşan yüzbinlerce satır, sorgunun cevabı olarak JVM’e dönülüyordu. Web arayüzünde zaten böyle bir cevap beklemeyen developerlar, herhangi bir paging de uygulamadıklarından, JVM’e, veri tabanından dönen satırlar için tonla nesne yaratmak dışında bir seçenek de bırakmıyorlardı.

Developerlara bu durumu ilettiğimizde, hızlıca gidip web arayüzüne bir kaç kontrol, zorunlu alan vs. filtreleri koydular ve problem ortadan kalktı. Problemi bulmak 2 küsür gün tuttu, çözmek en çok bir saatti! Ah şu developerlar olmasa ne kadar rahat olacak yazılım geliştirmek!

Developerlar eğer yaptıkları işi daha geniş bir perspektiften göremiyor ve “benim makinamda çalışıyor” ya da “ben test ettim, hiç bir problem yok” şeklinde konuşuyorlarsa, lütfen buna güvenmeyin. Bu tavra önem verin, bu tür sözlerin arkasını doldurmaya zorlayın onları ama sadece bu sözlerle ilerlemeyin. Ya da bir başka deyişle, her developerın bunu söyleme hakkı olmadığını bilin. Tam da bu yüzden architect/mimar vb. rollerle, sisteme çok farklı açılardan, yukarıdan, bakabilen, tecrübeli ve sistem anlayışına sahip kişilere ihtiyacımız var.

Kıssadan hisse: Yazılım geliştirme, developerlara bırakılamayacak kadar karmaşık bir iştir!

 

Toplam görüntülenme sayısı: 682

Alelade Hikayeler – I: Küçük Bir Performans Problemi

BT, Hikayeler, Java , ,

Yazılım dünyasında en sık yaşanan problemlerden birisi de, “performans” genellemesiyle anılan bir dizi problemdir. Problem bazen bir işlemin yapılmasının uzun sürmesidir, bazen son derece hızlı olan işlemlerin zaman zaman, muhtemelen sistemin yüküne bağlı olarak yavaşlamasıdır, bazen fazla bellek kullanımıdır, bazen de veri tabanından sorguların çok yavaş gelmesidir vs. Bu tür performans problemlerini çözmek bana daima en tatmin edici işlerden gelmiştir.

Bir gün ofisimde çalışırken, bir yazılım evi sahibi ve yöneticisi, feveran içinde bana ulaştı. Müşterileri için geliştirdikleri sisteme en son yaptıkları değişiklikleri devreye aldıklarında yaşadıkları ve kendilerini bir hayli zora koyan bir performans problemini çözecek kişiyi araştırırken bana ulaşmıştı. Bana telefonda söylediği şey, yeni yaptıkları deploymenttan sonra 10-15 dakika içinde sistem cevap veremez hale geliyor ve nihayetinde de çöküyordu. Sistem, Tomcat üzerinde çalışan ve tabi olarak Java ile geliştirilmiş, web arayüzlü ve kurum içinde, intranette pek çok kullanıcısı olan operasyonel bir bilgi sistemiydi.  Bundan dolayı sistemi kullanan müşterilerine karşı çok zor durumda kalmışlardı ve kendini çaresiz hissediyordu. Sistemin de tabi olarak kullanıcıları vardı ve eski sürüme dönerek hiç olmazsa işlerin devam etmesini sağlıyorlardı.

Bu konuşmadan yaklaşık 15-20 dakika kadar sonra, yaptığımız telefon görüşmeleri sayesinde, sıkıntılı olan sisteme erişmiş haldeydim. Ayrıca bu sistemin koduna da erişim sağladı müşterim. Sistem yöneticisi yardımıyla kabaca ne olup bittiğini anladıktan sonra bir-iki ufak ayar ile Tomcat’i tekrar başlattım ve ertesi sabah, kullanıcıların gelip sistemi kullanmaya başlamalarını bekledik. Tabi, ertesi sabah, çalışma saatini müteakip 10-15 dakika içinde sistem yine çalışamaz hale geldi ve JVM de bize bir dump üretti.

Elimdeki JVM dumpı ve sistemin Java kodlarına erişimim sayesinde yaklaşık 15-20 dakikada, hadi abarttım diyeyim, yarım saat içinde problemin sebebini, koddaki satırını hatta çözümünü belirlemiştim. Nihayetinde gözden kaçan çok basit bir kodlama hatasından kaynaklanıyordu problem. Kodun o parçası sonsuz döngüye giriyor ve her döngüde üretilen yeni nesneler GC tarafından toplanamadığından, çünkü nesneler bir torbaya (collection) konuyordu, belleği şişiriyordu.

Müşteriye durumu açıkladım, yapılması gerekeni de belirttim ve onlar da sistemi sorunsuz bir şekilde devreye aldılar. Onların derdi çözüldü, beni keyfim arttı ve para da kazandım.

Ama sanırım bu kısa hikayede göze çarpan başka noktalar da var. Neler mesela?

Bu hikayeden yazılım geliştirme ile ilgili olarak çıkarılabilecek olan dersler şunlardır:

  1. Eğer kodunuzu daha sakin kafayla, ne yaptığınızı düşünerek yazarsanız, çok yüksek ihtimalle böyle bir hata yapmazsınız.
  2. Eğer yazdığınız kodun birim testini yaparsanız, bu türden problemleri asla yaşamazsınız.
  3. Yazdığınız kodu makinanıza deploy edip, biraz doğru düzgün bir veri ile çalıştırsanız ki biz buna smoke test diyoruz, bu problemi yakalarsınız.
  4. Eğer kod gözden geçirmeleri (review) yaparsanız, sizin gözünüzden kaçsa bile, yorgundunuz, aile-sosyal hayatta stresleriniz vardı, vs., muhtemelen arkadaşlarınızın, daha tecrübeli olanların gözünden kaçmaz.
  5. Eğer sistemin entegrasyon testini yaparsanız, bu türden problemlerler çok daha az karşılaşırsınız.
  6. Eğer sistemin fonksiyonel testini yaparsanız, testerlarınızla, bu türden problemlerleri muhtemelen müşteri karşısına çıkmadan yakalarsınız.
  7. Yukarıdaki üç testi ve gözden geçirmeleri yaparsanız, herhangi bir test ya da tamamen informal bir gözden geçirme yapılsa bile, kesinlikle bu problem müşterinin önüne gelmez ve nerede bulduğunuza göre çok daha ucuza çözersiniz.

Bunlar, yazılım süreçlerini doğru işletmekle ilgili olarak yapılabilecek çıkarımlar. Genel prensipler açısından ise şöyle çıkarımlarda bulunabiliriz:

Belki 40-50 kişilik developer ve sistem yöneticisinden oluşan bir yazılım ve sistem ekibine sahip bir yazılım evinin ürettiği yüzbinlerce belki bir kaç milyon satırlık koddaki bir performans problemini bulmak yarım saati geçmeyen bir sürede başarılabiliyorsa, bu durumun sistemsel bir problem olduğu açıktır. Çok sıklıkla yaptığımız gibi, zeka ya da yetenek ile açıklayamayız bu farkı. Bu fark, sistemi tasarlayan, kodlayan ve deploy eden takımın içinde hiç bir şekilde bir performans farkındalığının olmamasıyla açıklanabilir. Ayrıca bu durum, bu takımda merak edip Java’nın performans problemlerini araştıran, etrafındakileri bilgilendiren meraklı kişilerin olmadığı şeklinde de okunabilir. Bu fark, sistemi tek tek developerların geliştirdiği ama kesinlikle “bir takımın” geliştirmediği şeklinde de okunabilir. Ve bu durum, gerekli temel bilgiye ve problemi bulup, analiz edip, çözme yetkinliklerine sahip bir kişinin, pek çok insanın günlerce, bilinçsizce problemle cebelleşmelerinden çok daha etkin bir şekilde sonuca ulaşabileceğini de gösterir.

Kıssadan hisse: İyi bir teoriden daha pratik bir şey yoktur. (There’s nothing more practical than a good theory. (Kurt Lewin))

Toplam görüntülenme sayısı: 728

Java’nın Performansı: Java Yavaş mı?

Java , , , ,

Uzun süredir yazmak istiyordum Java’nın performans ve optimizasyon konuları üzerine. Nasip 2014 yılının başınaymış.

Java ilk çıktığı andan bu yana genel olarak “yavaş” olmakla suçlanmakta ya da en azından yavaş oluşundan dem vurulmaktadır. Bu tür ifadelerin bir kısmı ciddi tecrübelere dayanmakla birlikte pek çoğunun ezbere edilen cümleler olduğunu ifade etmekte fayda var.

Öncelikle “yavaş” olmak üzerine eğilelim ve “yavaş” olmaktan ne kastediliyor ona bakalım. Java’nın neyi yavaş? Java ile geliştirilen yazılımlar mı yavaş yoksa dil olarak Java mı yavaş olan? Yoksa ikisi de mi? Şunu teslim edelim ki bir yazılım sisteminin performansı hangi dili ya da teknolojiyi kullandığından ziyade, nasıl bir mimari ile kurgulandığıyla ilgilidir. Donanım ve yazılım altyapısının nasıl kurgulandığı, farklı sub-systemler arası haberleşmeler, ön bellek (cache) kullanımı gibi mimari kararlar, çoğu zaman çok performanslı kod yazmaktan daha önemlidir. Çünkü sağlıklı kurgulanmış bir mimari ile çok mütevazi dil ve araçlar kullanarak, son derece performanslı yapılar oluşturulabilir. Örneğin yüzlerce hatta binlerce sunucunun paralel bir şekilde nasıl çok yüksek bir ölçeklenebilirlik (scalability) oluşturabildiğini ya da  ön bellek kullanımının performansı nasıl arttırdığını görmek isterseniz Facebook’un mimarisine bir göz atın derim. Bu amaçla buraya, buraya, buraya, buraya, buraya ve de buraya bakabilirsiniz. Bu şekilde PHP ile yazılmış bir web önyüze, C++ ve Java gibi dillerle yazılmış servis yapılarına ve MySQL üzerinde çalışan bir veri tabanı yapısına sahip dev bir mimarinin, örneğin 2011 sonu itibariyle saniyede 60 milyon sorguyu (query) nasıl karşıladığını, dahası bu sorguların %90’ının daha veri tabanına gelmeden ön bellek (cache) üzerinden nasıl cevaplandığını hayretle öğrenebilirsiniz. Yukarıda verdiğim linklerin sonuncusunda zaten Facebook’dan teknik bir uzman bir strateji olarak, bilenen ve yaygın kurumsal (enterprise) web, uygulama, veri tabanı, dosya vb. sunuculara tonla lisans ücreti ödemek yerine, AR-GE yaparak, kendilerine uygun bir mimariyi nasıl geliştirmeye para ayırdıklarını açıklıyor.

Zaman zaman rastlıyorum. Bir süre önce geliştirilmiş bir uygulama artık performans sıkıntısı yaşamaya başlıyor. Yazılımı geliştirenler biraz sistemi inceleyip, performansını iyileştirici işler yaptıklarında sistemin davranışı çok değişiyor, çok daha performanslı davranmaya başlıyor. Nedir yaptıkları? Muhtemelen dil seviyesinde değil de mimari seviyedeki iyileştirmelerle bu sonuç elde ediliyor. Elbette bu iyileştirmelerin dile uzanan kısımları da var ama çoğunlukla JVM parametrelerinde ya da uygulamanın topolojisine uygulanan değişiklikler, rahatlıkla uygulamanızın performansını çok ciddi boyutta rahatlatabilir.

Biraz da dil olarak Java’nın yavaşlığından ya da performansından bahsedelim. Java gerek CPU kullanımı dolayısıyla da zaman, gerekse bellek tüketimi açısından, selefi olan C ve C++ dillerinden daha problemlidir. Dolayısıyla Java temelde C ve C++ ile kıyaslanmaktadır. (Bunun sebebi de Java’nın da temelde bu iki dil gibi genel amaçlı olma ve özellikle iş yazılımları geliştirmede kurumsal ihtiyaçları karşılama iddiasındadır. İşin açıkçası, bu iddiada Java’nın çok önde oluşu su götürmez bir gerçektir.)  Çünkü bu diller, yapı olarak Java’dan çok farklılar. Bir başka deyişle Java, temelde C/C++’tan elde edilen tecrübe üzerine ve web gibi yeni gelişmelere cevap için geliştirildiğinden, tasarımı sırasında alınan örneğin (işletim sistemi ve donanımdan oluşan) platformdan bağımsız olması gibi özelliklerinden dolayı, tabiatı itibariyle daha yavaş çalışmaya meyilli olması normaldir. Burada “meyilli” kelimesini özenle kullandım çünkü, çıkışından bu yana Java derleyicileri (compiler) ve run-time ortamı olan JVMleri ile ilgili o kadar çok çalışma ve yenilik yapıldı ki, bunlar sayesinde kulağınıza inanılmaz gelecek ama Java kodunuzun, eşleniği olan C/C++ kodu kadar hatta daha hızlı çalışması mümkün hale geldi.

Yapısal olarak Java’yı C/C++’tan ayıran dolayısıyla da yavaş kılma ihtimali yüksek olan özelliklerini sıralamak istersek:

  • Platform bağımsız olması sanırım en önde gelir. Java nihayetinde JVM denen sanal bir makine, bir yazılım içinde çalışıyor, dolayısıyla, platformdaki kaynaklara yani CPU, bellek, threadler, hard disk, soketler vs. erişimi dolaylı yoldan olmaktadır. Bu da tabiati icabı bu erişimleri yavaş kılmakta. Tüm bu sıkıntılara Java’nın platformdan bağımsız olması için katlanıyoruz. Böyle bir durum söz konusu olmadığında Java kaynak kodunu doğrudan native koda derleme imkanınız var. Nitekim JVMlerin pek çoğunda bulunan JIT derleyicisi (Just-in-time compiler), kritik kod bloklarını anında-görüntü modunda, native koda çevirir. Bu durum tabi olarak aslında Java kodunun C kadar hızlı çalışabileceği fikrini aklımıza getiriyor. Facebook’un PHP ile yaptığı da bu aslında, PHP ile yazıp, native koda derleyip, native hızında çalıştırmak, eskiden bu yana bilinen bir taktiğin PHP’ye uygulanması, belli ki işe yarıyor.
  • Java nesne-merkezli bir dildir. Dolayısıyla Pascal ya da C gibi yordamsal dillerde int ya da float gibi basit tiplerle ama bölük-pörçük olarak ifade ettiğimiz yapılar Java’da daima çok daha bütünsel ve anlamlı olarak nesnelerle ifade edilir. Basit tipleri manipule etmek, nesneleri manipule etmekten daima çok daha kolaydır. Çünkü nesneler, bir ya da daha fazla basit tipi bir araya getirir ve bu veriler üzerinde çalışan fonksiyonlara da sahip olur. Bu yüzden nesneleri oluşturmak, yönetmek ve sonunda da bellekten silmek kesinlikle çok daha fazla kaynak isteyen bir iştir. Nesneler tabii olarak basit tiplerden çok daha fazla yer kaplar, nesneleri yazılımın katmanları, veri tabanı gibi diğer alt sistemler arasında gezdirmek daha fazla CPU ve belleğe ihtiyaç duyar. Java’da 8 basit tip dışında her şeyin nesne olduğunu, örneğin String’in bir nesne olduğunu, sıra dışı durumların (exceptions), dizilerin, iş alanı kavramlarının, kısaca her şeyin bir nesne olduğunu düşünün. Nesnelerin bir kalıtım hiyerarşisine sahip olduğunu (siz oluşturmasanız bile Java APIsindeki sınıflarda zaten derin hiyerarşiler vardır) ve nesneler üzerindeki metotların polymorphic olduğunu da düşünün.  Dolayısıyla Java’nın özellikle run-time ortamının daha fazla iş yaptığı ve bunun da Java’yı hantal kılacağı söylenebilir.
  • Java’da devamlı nesne oluşturmak zorunda oluşumuz, zamanı gelince nesneleri ortadan kaldırmak gibi bir derde de sebep oluyor. Malum, metotlarla ilgili run-time yapıları stackde tutulur. Yani run-timeda metotlar açıldıkça, JVM, yerel (local) değişkenlerini kendilerine has bellek alanı olan stackde tutar. Metotlarda oluşturduğunuz değişkenler, Java’nın 8 tane olan primitive tipinden ise, bu tür değişkenlere referans oluşturamadığınızdan yani bu basit türden olan değişkenler farklı metotlara ancak değerleri kopyalanarak geçildiklerinden, bu türden olan değişkenlerin ömrü, en çok içinde tanımlandığı bloğun/metodun ömrü kadardır. (Scope kurallarını hatırlayın.) Ama bir metot içinde nesne oluşturduğunuzda, stack sadece o metodun referansını tutar ve metot bittiğinde referansı temizlenir. Eğer nesnenizi, metot bitmeden farklı metotlara geçmişseniz, aynı nesneye yeni referanslar oluşturmuş olursunuz ve bu durumda o nesnenin ömrü, kendisine ulaşan referansların ömrüyle belirlenir. Yani bir nesneye referans olduğu müddetçe o nesne bellekte kalmaya devam eder. Bu durum da çok bilinen memory leak problemine sebep olur. (Bazılarımızın yaptığı gibi nesne oluşturmamak bellek problemine çare olabilir ama bu durumda da “Java görünümlü C” kullanıyor durumuna düşülecektir.) Özellikle iş uygulamalarının bolca nesne oluşturmaya yatkın yapısı, bu tür uygulamaların nihayetinde performans ve ölçeklenebilirlik problemleri yaşamasına sebep olmaktadır. Dolayısıyla bellek yönetimi Java’da ciddi bir problemdir ve bu hem JVM hem de geliştirilen yazılımlar açısından dikkatli bir şekilde ele alınmalıdır.

Internet’te pek çok yerde Java’nın yavaşlığı hakkında yazılar, benchmarklar ve tartışmalar bulursunuz. Mesela burada ve burada olduğu gibi. Ben, bunca yıllık tecrübemden sonra şunu rahatlıkla söyleyebilirim: Yavaş olan Java programcıları, Java değil. Javacılar olarak, kaliteli ve hızlı çalışacak kod yazmada o kadar geriyiz ki, ben malesef, senelerdir Java kodu yazan kişilerin JVM’in yapısı ya da ne bileyim ArrayList ile LinkedList’in uygun kullanım yerleri hakkında olması gerekenden çok daha az hatta hiç bilgi sahibi olmadıklarına, alışa geldikleri şekilde kod yazdıklarına çok sıklıkla şahit oluyorum. Elalemin saniyede binlerce transactionı başarılı bir şekilde çalıştırdığı Javayla biz yazılım geliştirdiğimizde, çok daha küçük sayılarla ifade edilen yüklerde bile sıkıntı çekebiliyoruz. Facebook’un ön tarafta PHP, arkada MySQL ile sağladığı performansın çok cüzi bir kısmını biz önde Java arkada Oracle DB ile sağlayamıyoruz. Unutmayın, ben bu ülkede “Oracle yavaş” diyenleri bile gördüm.

Şu bir gerçek: En temelde yukarıda saydığımız sebeplerden dolayı, C ve C++ gibi native çalışan dillerin gelişi güzel yazıldıklarında sağladıkları performansı Java’da sağlamak için, Javacıların,  C/C++ yazılımcılarından daha bilgili ve maharetli olması gerekli. Bu anlamda gelişi güzel yazılmış C kodu ile Java kodu arasında performans olarak örneğin 100 kat fark varsa, iyi yazıldıkları durumda bu farkın çok azaldığı hatta Java derleyicilerinin ve JVM’in yapısından dolayı, Java kodunun daha performanslı hale geldiğinden çok sıklıkla bahsedilir. Dolayısıyla Javacılar, mimari, algoritmik karmaşıklık gibi seviylerde çok iyi olmakla birlikte Java dilini de çok verimli kullanmak zorundalar. Aksi taktirde çok sıklıkla karşılaştığımız sıkıntılı durumlara düşmek işten bile değil.

Yazımızı, Java’nın temelde “hızlı çalışma” için ortaya çıkmadığını hatırlatarak son verelim. Javacılar için modulerlik, lowly-coupled, highly-cohesive dolayısıyla da daha rahat değişebilen yapılar ortaya çıkarmak, etkin, hızlı çalışan kod yazmaktan pek tabi daha önemlidir. Ama bu Java kodunun son derece yavaş ve hantal olması anlamına gelmez. Gerektiği kadar hızlı ama düzenli bir mimari ve kod yapısı her zaman tercihe şayandır. Biraz bilgi ve gayret ile son derece hızlı ve ölçeklenebilir Java yazılımları geliştirmek çok da zor değildir.

İyi bir performansa sahip Java kodu için aslında aslında yapmamız gereken ilk şey, bu durum hakkında bir farkındalığa sahip olmaktır.

“Hızlı” Java kodlu günler dilerim 🙂

Toplam görüntülenme sayısı: 3133