Geçen sene Spring Boot 2.2.0 release notlarında bahsi geçen performans iyileştirmelerini gözlemledikten sonra elde ettiğim bulguları şu yazı ile paylaşmıştım: Spring Boot 2.1 vs 2.2: Bellek Kullanımı ve Başlangıç Süresi İyileşmiş
https://start.spring.io/ üzerinden an itibariyle seçilebilen Spring Boot versiyonlarını Java 11 ile ayrı ayrı VisualVM ile gözlemleyerek, yeni bir Spring Boot projesi oluştururken yapacağımız seçimlerin performansa ve kaynak kullanımına ne gibi etkileri olabileceğini yeniden gözlemlemeye çalıştım.
LTS versiyon olmadığı için Java 15 ile ilgilenmedim; onun yerine Java 17’yi beklemeyi düşünüyorum. Ayrıca önceki yazıda Java 8’den Java 11’e geçişte bariz bir iyileşme sağlandığı için Java 8 ile de ilgilenmedim.
Gelelim sonuçlara:
| Spring Boot | 2.2.12 | 2.3.7 | 2.4.1 |
| Final “ayrılmış” bellek (heap size) | ~383 MB | ~383 MB | ~383 MB |
| Final “kullanılan” bellek (used heap) | ~67 MB | ~70 MB | ~237 MB |
| Maksimum “kullanılan” bellek | ~248 MB | ~214 MB | ~237 MB |
| Uygulama başlangıç süresi | ~9.5 sn | ~9.7 sn | ~11 sn |
Not: Önceki yazı sırasında gözlemleri farklı bir uygulama üzerinde yaptığımdan buradaki değerlerle karşılaştırmak yanlış olur.
2.2.12’den 2.3.7’ye geçerken bir miktar iyileşir gibi olan maksimum “kullanılan” bellek dışında bir iyileşme gözlemleyemedim. İyileşme gözlemleyememek bir yana, 2.4.1’e giderken tablo bir miktar kötüleşiyor hatta…
Bu yazıda geçen yazıdaki gibi dramatik bir sonuç çıkmadı. Zaten her yeni Spring Boot versiyonu da performans / kaynak kullanımı iyileştirmesi vaat etmiyor. Ben yalnızca geçen sürede bir şeyler değişmiş mi gözlemlemek istedim…
“Gözlem” derken?
Bu iki yazıda yaptığım şeyi özellikle “performans testi” yerine basitçe “gözlem” olarak nitelendiriyorum. Performans testi gibi daha fazla değişkenin faklı bakış açılarıyla ele alınacağı, daha ciddi uğraş gerektiren bir çabaya henüz girmedim.
Diğer taraftan, dikkatinizi çekmek istediğim başka bir nokta var: Örneğin farklı “garbage collector” türleri ve farklı JDK dağıtımları arasında karşılaştırmalar yapmak gibi uğraşlara da girilse, uygulamanın gerçek çalışma zamanı metrikleri de elde edilse, en nihayetinde burada ortaya çıkacak değerler uygulama karakteristiğine göre değişecek ve uygulama gereksinimlerine göre farklı yorumlanmak durumunda kalacak. Örneğin bir “batch” uygulamasının “key” performans metriği başlangıç süresi ve bellek kullanımından ziyade belirli bir zaman aralığında kaç kayıt işlediği olabilir. Benzer şekilde, örneğin bir REST API uygulamasının eş zamanlı kaç isteği, ne kadar bellek kullanarak, ve ortalama kaç milisaniyede işleyebildiği o uygulamanın asıl irdelenmesi gereken metrikleri olabilir. Bunlar gibi metrikleri ölçecek ve değerlendirecek yazılarda görüşmek dileğiyle…
Ufuk Uzun 