performans

Bir Algoritma Bağlamında Güzellik ve Performans – II

Bilgisayar Bilimleri, Java , ,

Bir önceki yazıya kaldığımız yerden devam edelim.

Tüm bu ölçümler sonuçta JVM’ler üzerinde herhangi bir oynama yapmadan elde edildiler. Algoritmanın performansını arttırmak için yapılacak bir şey var mı diye bakınca aslında algoritmanın kodunda zaten ufak bir-iki iyileştirmenin yapıldığı görülmektedir. Yani algoritmada

double distance = Math.sqrt(Math.pow(x, 2) + Math.pow(y,2));

satırı

double distance = x * x + y * y;

satırı ile değiştirilmişti. Bu ise bizi hem Math.sqrt() ile kare kök almaktan hem de her döngüde iki defa Math.pow() çağrısı yapmaktan kurtardı. Yukarıdaki kodu Math.sqrt() ve Math.pow() metot çağrıları yapacak şekilde değiştirince, n=1000000 için örneğin MacBook Pro’daki 41,70 mili second olan süre yaklaşık 46 miliseconda, n=10000000 için de 415,90 mili seconddan 445 mili seconda çıkıyor. Bu demektir ki biz zaten kodumuzda bu iki metot çağrısını yapmayarak yaklaşık %10luk bir performans artışı kazandık.

Bir başka hızlandırma noktası da rastgele sayı üretimi olabilir. Açıkçası JDK ile gelen yapıların o konudaki en hızlı en optimize kodlar olmadığını tecrübemle biliyorum. Örneğin daha önce de java.util.StringTokenizer‘ı kendim geliştirdiğim çok daha hızlı ve amacım açısından optimize edilmiş bir başka tokenizer ile değiştirmiştim. Aynı şeyi java.lang.Math sınıfındaki random() metodu için de yapabiliriz. Bu durumda ilk akla gelen java.util.Random sınıfı oluyor. Bu sınıfın nextDouble() metodunu kullanınca performansta pek bir değişik olmadı. Sebebi de tam tahmin ettiğim gibi, java.lang.Math sınıfının random() metotu zaten java.util.Random sınıfını kullanıyor 🙂

Apache Commons’daki Math kütüphanesinde de bayağı rastgele veri üreten yapılar var. Dolayısıyla buradaki bir kaç yapıyı denedim ve org.apache.commons.math.random paketindeki MersenneTwister sınıfı mükemmel sonuç verdi. Bu sınıfı kullanmak için koddaki sınıfa

private static BitsStreamGenerator randomData = new MersenneTwister();

satırını ekledim ve

double x = Math.random();
double y = Math.random();

satırlarını

double x = randomData.nextDouble();
double y = randomData.nextDouble();

ile değiştirdim. Macbook Pro üzerindeki şu sonuçlara bakın:

n Süre (ms) Error (%)
10 0,00 16,92
100 0,10 2,91
1.000 0,30 1,34
10.000 1,30 0,4112
100.000 3,60 0,139
1.000.000 19,50 0,047539
10.000.000 188,70 0,013136
100.000.000 1898,00 0,004824
1.000.000.000 19534,90 0,001324

Bu tablodan çıkan sonuç şu, n=10.000 için henüz bir performans ilerlemesi yok ama daha yüksek n sayıları için MersenneTwister sınıfı mükemmel bir performans gösteriyor. Örneğin n=10.000.000 için %57lik, n=100.000.000 için %53lük, n=1.000.000.000 için ise benzer şekilde %52lik bir performans ilerlemesi elde ettik. Burada Apache Commons Math kütüphanesinin hem 2.2 hem de 3.3 sürümlerini kullandığımı ama yukarıdaki sonuçları 2.2 ile aldığımı belirtmeliyim. İlginç bir şekilde 3.3 sürümü, 2.2’ye göre yaklaşık %10 daha yavaş çalıştı. Tabi rastgele sayı üretmek zor iştir, üretilen sayıların rastgele olması açısından olabildiğince bağımsız olması önemlidir. Burada kullandığım MersenneTwister sınıfı için bu konuda daha ayrıntılı bilgi almak isteyenler buraya bakabilirler.

Muhtemelen daha hızlı rastgele sayı üreten yapılar bulunup bu performans daha da arttırılabilir.

Bir sonraki yazıda ise JVM tuning ile neler yapabiliriz buna bakalım.

 

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

Bir Algoritma Bağlamında Güzellik ve Performans – I

Bilgisayar Bilimleri, Java , ,

Monte Carlo metodu, algoritmik çözümü zor olan matematiksel ve fiziksel problemleri, rastgele (random) sayılar üreterek, simule ederek çözmeyi amaçlayan yaklaşımlara verilen ortak addır. Monte Carlo’daki gazinolardaki kumar aletlerinin rastgele sonuç üretmesine atıf olarak bu isim verilmiştir. Optimizasyon problemlerinde sıklıkla kullanılır.

Monte Carlo metodunu, pi sayısını bulmak için de kullanabiliriz. Bakın şöyle: Kartezyen koordinat sisteminde merkezi (0,0) noktasında olan ve yarı çapı 1 birim olan bir çember çizin ile bu çembere teğet geçen bir de kare çizin. Çemberin ve karenin alanlarının oranı pi/4 yapar. Bu şu demektir: Bu çizime rastgele bir nokta atarsanız, bu noktanın, çemberin içine düşmesi ihtimali pi/4 eder.

Bu gerçeği tersten okuyalım şimdi de: Eğer bu çizime sonsuz tane nokta atılırsa, bu şekli tamamen kapsamış oluruz. Yani bu şekile n tane nokta atalım ve bu noktaların r tanesinin çemberin içine düştüğünü varsayalım. n sonsuza giderken, 4r/n oranının pi‘ye yaklaştığını görürsünüz. n‘yi 1 yaparsanız, yani 1 nokta atarsanız bu oran ya 0 ya da 4 olacaktır. n sayısını arttırdıkça bu oranın gittikçe pi sayısına yakınsadığını, ne kadar çok nokta atarsanız, pi‘nin gerçek değerine (ki böyle bir şey yok! dolayısıyla daha doğru tabirle, virgülden sonraki rakamları doğru bir şekilde bulmaya başlarsınız) yakınsarsınız. Bu durumu şuradaki ya da şuradaki applet ile görebilirsiniz ya da Youtube’taki pek çok videodan birini seyredebilirsiniz.

Bu algoritmayı Java ile şöyle gerçekleştirebiliriz:

import java.util.Scanner;

public class MonteCarloPI {
	public static void main(String[] args) {
		int dotsInCircle = 0;
		System.out.print("Number of points: ");
		Scanner in = new Scanner(System.in);
		int n = in.nextInt();
		
		double start = System.currentTimeMillis();
		for(int i = 0; i<n; i++){
			double x = Math.random();
			double y = Math.random();
//			double distance = Math.sqrt(Math.pow(x, 2) + Math.pow(y,2));
			double distance = x*x + y*y;
			if(distance <= 1.0)
				dotsInCircle++;
		}
		double finish = System.currentTimeMillis();
		
		double seconds = (finish-start)/1000;
		double myPI = (double) 4*dotsInCircle/n;
		System.out.println("My PI is: " + myPI + " and Java's PI is: " + Math.PI);
		System.out.println("Time is: " + seconds);
	}
}

Yukarıdaki program, girilen sayı kadar rasgele (x, y) noktası üreterek, her bir noktanın (0, 0) merkez noktasına uzaklığı hesaplanır ve bu uzaklığın 1’e eşit ya da ondan küçük olup olmadığı kontrol edilir, eğer eşit ya da küçük ise, bu demektir ki nokta çemberin içine düşmüştür ve yukarıdaki algoritmanın anlatımında r dediğimiz ve programda dotsInCircle ile temsil ettiğimiz değişkenin değeri arttırılır.

Yukarıdaki kodu n=1 için çalıştırırsanız sonuç ya 0 ya da 4 çıkacaktır. Çünkü o tek nokta ya dairenin içine ya da dışına düşecektir. Dolayısıyla salınım 0 ile 4 arasında gerçekleşecektir. Ama örneğin n=10 yaparsanız gelebilecek sonuçlardan birisi şöyle olabilir: Hesaplanan pi = 2.800000  ve hata yüzdesi %10.873232. Yani yaklaşık %11 hatayla Java’nın Math sınıfındaki PI’ye (3.141592653589793) yakınsanmış demektir. Ama n sayısını 1.000.000.000 yapınca pi = 3.141536  ve hata yüzdesi % 0.001809 olarak elde ettim.

Tabi sağlıklı ortalama değerler için, aynı n sayısı için olarak olabildiğince çok çalıştırma yapılmalıdır. Ben de bu amaçla yukarıdaki algoritmayı aşağıdaki gibi değiştirdim.

package org.javaturk.oop.ch05;

import java.util.ArrayList;
import java.util.List;
import java.util.Scanner;

public class MonteCarloPITiming {
	private static int runCount = 100;
	private static int n;
	
	private static List<Double> pis = new ArrayList<Double>();
	private static List<Double> times = new ArrayList<Double>();
	private static List<Double> percentages = new ArrayList<Double>();
	
	public static void main(String[] args) {
		System.out.print("Number of points: ");
		Scanner in = new Scanner(System.in);
		n = in.nextInt();
		for(int i = 0; i < runCount; i++){
			calculatePI();
		}
		printResults();
	}

	private static void printResults() {
		double meanTime = 0;
		double meanError = 0;
		System.out.printf("%10s %10s %10s\n", "Time  ", "Calculated PI", "Error %  ");
		for(int i = 0; i < runCount; i++){
			meanTime += times.get(i).doubleValue();
			meanError += percentages.get(i).doubleValue();
			System.out.printf("%10f %10f %10f\n", times.get(i).doubleValue(), pis.get(i).doubleValue(), percentages.get(i).doubleValue());
		}
		meanTime /= runCount;
		meanError /= runCount;
		System.out.printf("Mean time: %10f\n", meanTime);
		System.out.printf("Mean error: %10f", meanError);
	}

	public static void calculatePI() {
		int dotsInCircle = 0;
		double start = System.currentTimeMillis();
		for (int i = 0; i < n; i++) {
			double x = Math.random();
			double y = Math.random();
			// double distance = Math.sqrt(Math.pow(x, 2) + Math.pow(y,2));
			double distance = x * x + y * y;
			if (distance <= 1.0)
				dotsInCircle++;
		}
		double finish = System.currentTimeMillis();
		double seconds = (finish - start);
		times.add(seconds);
		double myPI = (double) 4 * dotsInCircle / n;
		pis.add(myPI);
		double diff = Math.abs((Math.PI - myPI)); 
		double percentage = diff * 100 / Math.PI;
		percentages.add(percentage);
	}

}

Yani programın başındaki runCount (ki değeri 100) kadar aynı n sayısı için algoritmayı çalıştırıyorum ve her çalışmanın sonuçlarını List nesnelerine koyuyorum. runCount defa çalışma bitince de hem sürenin hem de hata yüzdesinin ortalamasını alıyorum. Beklentim şu: n arttıkça süre de artacak çünkü daha çok nokta atacağım ama tabi olarak hata yüzdesi azalacak çünkü pi‘ye daha çok yakınsayacağım. Örneğin farklı n sayıları için aşağıdaki ortalama ölçümleri elde ettim:

MacBook Pro i7 2,5 GHz. 16 GB RAM, MacOS 10.10.1 Yosemite konfigürasyonunda:

n Süre (ms) Error (%)
10 0,20 16,02
100 0,30 2,683942
1.000 0,40 1,423435
10.000 1,10 0,505523
100.000 4,90 0,104983
1.000.000 41.70 0,041766
10.000.000 415,90 0,011628
100.000.000 4097,10 0,002976
1.000.000.000 41001,00 0,00116

Toshiba Satellite i7 2,4 GHz. 8 GB RAM, Windows 8.1 konfigürasyonunda:

n Süre (ms) Error (%)
10 0 15,278875
100 0 5,337467
1.000 0 1,097579
10.000 1,6 0,3616
100.000 6,2 0,086118
1.000.000 48,5 0,037688
10.000.000 465,7 0,011813
100.000.000 4646,8 0,003846
1.000.000.000 45751 0,000768

Her iki konfigürasyonda da Java 1.8.0_25 HotSpot 64-bit server JVM çalışıyordu.

Yukarıdaki sonuçlardan şunları söyleyebiliriz:

  • Algoritmada n tane for döngüsünün her birinde iki defa Math.random() çağrısı, iki defa çarpma işlemi, bir tane kıyas (<=), bir tane de artım yapılıyor. Dolayısıyla algoritmanın karmaşıklığı 0(n) (bigO(n)) görünüyor. Yani algoritmanın zaman ihtiyacı doğrusal olarak artacaktır. Zaten sonuçlar da bunu gösteriyor. n sayısı 10 katına çıkınca, gerekli süre de yaklaşık 10 katına çıkıyor.
  • İkincisi konfigürasyonları çok yakın, JVMleri aynı sürüm olmasına rağmen MacBook Pro, Toshiba’dan yaklaşık %10 civarında daha hızlı çalıştı. Bu durum MacBookPro’daki CPU’nun biraz daha hızlı olması yanında envai çeşit farklı faktörler üzerinden açıklanabilir. Çok önemli bir fark değil açıkçası.

Bu algoritma o kadar basit ki, anlaşılması, kodlanması vs. çok kolay. Ama bu algoritma bir o kadar da güzel, güzel ötesi, neffiiisss. Matematiğin ve sayıların güzelliğini ortaya koyuyor, herkesin anlayacağı basitlikte.

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

Yazılımların Performansı ve Performans İyileştirme

Java

Java’nın performansı ile ilgili olarak daha önce bu yazıyı yayınlamıştım. Şimdi bu konuda biraz daha temel tanımlar ve metot üzerinden ilerleyelim. Sonrasında Java’ya özel performans konularını ele alırız.

Aslında performans derken birden fazla şeyi kastederiz, dolayısıyla performans kelimesi aslında “hız” etrafında kümelenmiş pek çok farklı kalite kriterinin şemsiye ismidir. Bakın o şemsiye altında neler olabilir:

  • Son kullanıcı cevap zamanı (responsiveness): Son kullanıcının sistemi kullanırken yaptığı hareketlere yönelik sistemin cevap verme zamanıdır. Son kullanıcıyı en fazla ilgilendiren ve uzun olduğunda canını sıkan ve çalışma ritmini bozan faktördür. “Sistem yavaş” dendiğinde çoğu zaman bu kastedilir ama çok farklı sebepleri olabilir. Performans iyileştirme çalışmalarının en öncelikli hedefi, son kullanıcı cevap zamanını makul seviyelere indirmek ve ortalama olarak kabul edilebilir bir son kullanıcı performans sağlamaktır.
  • Ölçeklenirlik (scalability): Uygulamanın davranışının artan yük altında nasıl değiştiğini ifade eder. Ölçeklenirliği en temelde etkileyen iki faktör, artan canlı kullanıcı sayısı ve büyüyen veri miktarıdır. Ölçeklenirliği kötü olan sistemlerin son kullanıcı cevap zamanı da kötüdür. Ama bu durum her zaman ortaya çıkmaz, bazen belli zamanlarda daha fazla görünür olur. Bu durum tamamen sistem yükünün devamlı değişir yapıda olmasından kaynaklanır. Performans iyileştirme çalışmalarında ölçeklenirlik, son kullanıcı cevap zamanını makul sınırlarda tutacak şekilde, ikinci öncelik olarak ele alınır.
  • Bellek kullanımı (memory footprint): Uygulamanın bellek kullanımıdır. Genelde bellek kaçağı (memory leak) olarak ortaya çıkar ve kurumsal uygulamaların ölçeklenirliğini en fazla etkileyen faktördür. Bellek kaçakları, Java ile geliştirilmiş uygulamalarda çöp toplama (garbage collection) mekanizmasının sık ve uzun sürelerle devreye girmesine sebep olduğundan ve bu faaliyet ciddi kaynak tükettiğinden, nihayetinde son kullanıcı cevap zamanını menfi yönde etkiler. Bellek kullanımı iyileştirilmediği taktirde, nihayetinde ölçeklenirliği tamamen ortadan kaldırır ve sistemleri, sıklıkla tekrar başlatılması gerekli hale getirir. Performans iyileştirme çalışmalarınında bellek kullanımına el atmadan ya da çöp toplama faaliyetini optimize etmeden sağlıklı bir ölçeklenirlik elde etmek zordur.
  • Üretilen iş (throughput): Belli bir zamanda uygulamanın ürettiği iş miktarıdır. Özellikle toplu yapılan basım, faturalandırma, görüntü işleme, veri aktarımı vb. işlerde çok daha önemli hale gelir, çünkü aslolan bir raporun basılmasının ya da bir abonenin faturasının oluşturulmasından ziyade, belli bir sürede bu işlerden ne kadar çok yapıldığıdır. Bundan dolayı çoğu zaman bu kriter, son kullanıcı cevap zamanı ile çelişen tabiata sahip olur. Örneğin bir abonenin faturasını 10 saniyede üreten bir sistem, bu performans ile son kullanıcısını memnun etmeyebilir. Ama aynı sistem arka tarafta batch olarak, paralel işlem yaparak, saatte 1,000,000 tane fatura üretiyordur ve bu durum son derece kabul edilebilir bir iş üretimi olabilir. Performans iyileştirme çalışmalarınında üretilen işi arttırıcı çalışmalar, uygulamanın mahiyetine göre değişecek şekilde gerekebilir.
  • Başlama zamanı (startup time): Uygulama ilk başlatılırken, kullanıcı isteklerine cevap vermek için hazır oluncaya kadar geçen zamandır. Bu kriter çoğunlukla istemci (client) tarafındaki uygulamalar için önemlidir. Örneğin kendi kişisel makinanızdaki bir kelime işlemcinin iconuna tıkladıktan ne kadar süre sonra kullanıma hazır hale geldiği, son kullanıcılar olara gittikçe daha fazla dikaktimizi çekmektedir. Bundan dolayı örneğin yılardır kullandığımız mekanik hard diskleri, çok daha hızlı olan SSDlerle değiştiriyoruz.  Fakat sunucu (server) tarafındaki uygulamaların örneğin 15-20 dakikada ayağa kalkıyor olması her zaman problem olarak görülmeyebilir. Bundan dolayı bu kriter performans iyileştirme çalışmalarınında genellikle çok da öncelikli olarak ele alınmaz.

Performans iyileştirme çalışmalarında yöntemsiz, gelişi güzel gitmek çoğu zaman sıklıkla karşılaştığımız bir durumdur. Bundan dolayı attığımız taşın ürküttüğümüz kurbagaya deyip deymemesi durumu söz konusudur. Örneğin ortalama olarak 10 saniyede cevap olarak dönen bir arama arayüzünü hızlandırmak için zaman harcayıp sonunda 8 saniyeye indirmiş olmak hiç bir zaman kullanıcı tarafında taktir edilecek bir durum olarak görünmeyecektir. Bu kadar uğreşmak yerine 10 saniye boyunca işlemin durumunu gösteren bir progress bar çıkarmak, son kullanıcıyı, aramanın 8 saniyeye indiği duruma göre daha fazla memnun edebilecektir. Çünkü aslolan son kullanıcının algısıdır. Bundan dolayı son kullanıcı cevap zamanı iyileştirmelerinde, nereye bakmanız, neyi ne kadar iyileştirmenizin gerektiği son derece önemlidir.

Performans iyileştirme çalışmalarında yapılan bir başka yanlış da var olan durumu tespit etmemek ya da edememektir.  Bu durum çoğu zaman teknik bir problem olarak ortaya çıkar. Yani örneğin müşterinin çektiği performans sıkıntısının aynısını üretmekte zorlanırsınız, gerçek ortamda da o sıkıntıyı ölçmeniz zordur. Kendi test ortamınızda ölçüp, iyileştirmeyi yapıp sonra yine aynı şartlarda performansı ölçmeniz gereklidir ki ne kadar yol katettiğinizi anlayabilesiniz. Dolayısıyla ölçüm yapmak, çok sayıda ve aynı şartlarda ölçüm yapmak, olabildiğince ortalamalar üzerinden gitmek, performans iyileştirme çalışmalarının dikkat edilmesi gereken önemli noktalarındandır.

Yöntemden bahsetmişken, basit adımlardan oluşan bir performans iyileştirme sürecinden bahsedebiliriz. Performansı sıkıntılı olan bir yazılım sisteminde iyileştirmeler yapmak için aşağıdaki adımları takip edebiliriz:

  1. Performans problemlerini tanımlamak ve listelemek,
  2. Her bir problemin performansını ölçmek ve iyileştirme hedefini belirlemek,
  3. Problemleri önceliklendirmek,
  4. En yüksek öncelikli problemi ele almak,
  5. Problemin iyileştirme gerektiren noktalarını belirleyip üzerinde çalışmak,
  6. İyileştirilmiş performansı ölçmek,
  7. 5. ve 6. maddeyi, performans hedefini yakalayana kadar tekrar etmek,
  8. 4. maddeden devam etmek.

Bu şekilde bir süreç ile, nereden nereye geldiğimizi belirleyebileceğimiz gibi, değer katan iyileştirmelerde bulunma ihtimalimiz de artmış olur.

Yukarıda tarif edilen süreci kullanarak hedef performans ölçütlerine ulaşmak için temelde üç farklı çözüm şekli kullanılır:

  • Kod değişikliği: Performans olarak sıkıntılı kod parçacıklarını daha etkin çalışanlarla değiştirmektir. Kodda yapılacak değişikliklerle çözüme ulaşmak çoğu zaman en hızlı bulunan ve en hızlı iyileştirilendir. Bu tür kod değişiklikleri hem algoritmik hem de dil tabanlı olabilir. Fakat bu tür değişikliklerin etkisi çoğu zaman azdır.
  • Mimari değişiklik: Yazılım sisteminin alt parçalarınında yapıalcak organizasyonel değişıkliklerdir. Yaygın kod değişiklikleri çoğu zaman kendini mimari değişikliğe çevirir. Mimari değişikliklerin hem maliyeti yüksektir hem de sağladığı iyileştirme oranı çok daha iyidir. Cache kullanmayan bir sistemin cache kullanmaya başlaması ya da veri tabanında örneğin partition kurgulamak vb. yazılım mimarisi değişiklikleri çok sık yapılan iyileştirme çalışmalarındandır. Mimari değişıklikler her zaman kod değişıkliği olarak ortaya çıkmaz, örneğin daha hızlı CPUlara ya da yüksek RAMe sahip olacak şekilde donanım altyapısını iyileştirmek, ağ altyapısını düzenlemek ya da istemcileri güclendirmek de bu tür mimari iyileştirmelerdendir.
  • JVM tuning: Java’nın çalışma zamanı mekanizması olan JVM’in davranışının gözlemlenmesi ve sistemin ihtiyaçlarını karşılayacak şekilde düzenlenmesidir. JVM tuning çalışması, genel olarak JVM’in ayağa kalkarken aldığı parametrelerin düzenlenmesidir. Bu parametreler bellek, çöp toplayıcı, JIT vb. konularla ilgilidir olup genelde her yeni Java SE sürümüyle birlikte ciddi yeniliklerle gelmektedir. Bu amaçla çalışµa zamanında JVM(ler) gözlemlenir, çoğu zaman ayarla-gözlemle-değiştir şeklindeki bir çevrimle parametreler optimum noktaya getirilir. JVM tuningin özellikle gerçek ortam üzerinde, canlıya geçiş öncesinde yapılıp, belli aralıklarla tekrarlanması gereklidir.

Performans ölçümleri dolayısısıyla da gerektikçe performans iyileştirme çalışmaları, bir projenin, yazılım ürününün hayatında farklı evrelerde yapılabilir. Bu evreleri şöyle özetleyebiliriz:

  • Mimariyi kurgularken: Performans ile ilgili en temel çalışmaların yapılması gereken evredir. Elimzide var olan performans ihtiyaçlarını karşılayacak şekilde bir çekirdek mimari kurup, gerekli ölçümleri yapmak ve icap eden değişikliklerden sonra bu çekirdeği nihai mimari olarak kabul etmek, performans konusunda sıkıntı çekmemek için yapılması gereken ilk çalışmadır. Sıkça ıskalananması ile bilinir 🙂
  • Kod geliştiriken: Kritik performans ihtiyaçlarını karşılamada şüphelenilen kod parçalarının daha geliştirilirken ölçülmesi ve iyileştirilmesidir. Dolayısıyla da kodun henüz check in yapılmadan performansının iyileştirilmesi, ilk madde gibi genelde ıskaladığımız ama performans amacıyla yapılacak değişikliğin maliyetini en az seviyede tutan çalışmadır.
  • Test süresince: Fonksiyonel ve performans testleri süresince genelde kod değişikliği ve mimari değişiklikler yerine getirilir. Uygulamanın ölçeklenirliğin belirlenmesi için fonksiyonel testler dışında yük (load) testlerinin de yapılması gereklidir. Test çalışmalarında JVM tuning ile ilgili bazı bulgular da elde edilir ama bu kısma henüz fazla önem verilmez. Dolayısıyla temelde yük testleri söz konusudur. Yük testleri, test otomatizasyon araçları yardımıyla, uygulamaya uygun yük sağlayarak yapılır ve temelde uygulamanın ölçeklenirliğini test etmek için kullanılır.
  • Canlı öncesi: Canlıya geçiş öncesinde, uygulamanın gerçek ortama taşınmasıyla ortaya çıkabilecek yeni performans problemleri ile canlı ortamın JVM mimarisinin ayarlanması ve JVM tuninginin yapılması söz konusudur. Bu amaçla aşağıdaki yoğun yük testler söz yapılır.
  • Canlı sonrası: Canlıya geçiş sonrasında uygulamanın gözlemlenmesi (monitor) ve ortaya çıkan performans problemlerinin giderilmesidir. Bu çalışma daha çok, canlı öncesi oluşturulan JVM mimarisinde iyileştirilmeler yapılmasını gerektirecektir.

Performans problemlerimiz sıkıkla, ıskaladığımız mimari çalışmaların bir bedeli olarak ortaya çıkar ve bu topraklarda genelde donanım altyapısına bol para akıtarak çözülmeye çalışılır. Halbuki bir önceki yazıda verdiğim Facebook örneğindeki gibi sağlıklı mimari çalışmalar ve erken tanılarla bu problem devasa boyutlara çıkmadan önlenebilir.

Performans problemsiz projeler dilerim 😉

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

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ı: 3182

1 2 3