Üretim Hattında Spring (2)

Spring Çalışma Zamanı: Kurumsal Servis Katmanı

Spring çalışma zamanı tarafından sağlanan kurumsal servis desteği çekirdeğin (kernel) üzerine kurulmuştur. Spring kapsamlı bir kurumsal servis desteği sunmaktadır. Biz burada en yaygın kullanılan bileşenlerinden bazılarına odaklanacağız.

Transaction Yönetimi

Çalışma zamanındaki transaction yönetim desteği iki faza sahiptir. Uygulama bağlamının (application context) oluşturulması aşamasında transaction alt sistemi @Transactional annotasyonlarını ve “tx namespace”indeki XML tanımlarını işleyerek uygulama bileşenlerinden transaction desteğine ihtiyaç duyanları dekore eder. Çalışma zamanı safhasında ise, bir önceki safhada oluşturulan “transaction interceptor” her transactional operasyonun öncesinde ve sonrasında çağırılır. Interceptor’ün görevi transaction metadatasındaki yayılım (propagation) tanımlarına göre transactionların başlatılması, bitirilmesi, askıya alınması, kaldığı yerden devam ettirilmesi veya gerisin geriye alınması işlemlerini gerçekleştirmektir. Spring transaction yönetim platformu, alt taraftaki sistem transaction yönetim katmanına izolasyon derecelerinin ve salt okunur davranışların düzgün biçimde iletilmesini sağlar.
Transactional bir metod içerisinden bir exception fırlatıldığında, transaction altyapısı mevcut transaction’ın gerisin geriye alınıp alınmayacağına karar verebilmek için exception tipine göre geriye alma kurallarını (rollback rules) yorumlar.
Transaction altyapısında meydana gelebilecek herhangi bir arızanın atomik olmayan güncellemeler yapılması, kirli okumaların (dirty reads) gerçekleşmesi ve veri bütünlüğü ile ilgili diğer arzu edilmeyen durumların ortaya çıkması gibi ciddi sonuçlara yol açacağı aşikardır.

Veri Erişimi

Spring’in veri erişim desteği, sistemde kullanılan teknolojiye bağlı olarak (JDBC, JPA, iBATIS, Hibernate, Toplink etc.) değişebilen birbirinden bağımsız alt sistemlerden oluşmaktadır. Bu veri erişim alt sistemleri aynı transaction içerisinde, örneğin Hibernate ve JDBC, bir arada da kullanılabilir. Spring çalışma zamanı, “persistence” oturumlarını yönetir ve fırlatılan exception’ları kendi DataAccessException hiyerarşisindeki karşılıklarına çevirebilmek için veri erişimi ile ilgili her operasyonda devreye girer.
Spring çalışma zamanı, JDBC tabanlı veri erişiminde ilgili operayonlarda detaylı biçimde – dönen sonuçların iterasyonunun yönetilmesi, SQL verisinin alan nesnelerine çevrimi, saklı yordamların (stored procedures) çağırılması vb işlerde – görev alır.
Veri erişimi ve transaction yönetim altyapısı arasındaki entegrasyon neredeyse bütün kurumsal uygulamaların hayati öneme sahip bir kısmını oluşturur.

Mesajlaşma

Spring’in mesajlaşma desteğinin merkezinde yer alan bileşen “message listener container”lardır. Bu container mesaj tabanlı uygulamalar ve mesajlaşma sağlayıcılar arasında yer alan ara bir katmandır. Bu “container”lar mesaj alabilmek için mesajlaşma sağlayıcılara kayıt olunmasından, mesajların işlenmesi için “thread”lerin yönetilmesinden, ve mesajların uygulama bileşenlerindeki metodlara sevk edilmesinden sorumludur. Mesajlaşma altyapısı, bunların yanında transaction’lara katılmayı, kaynakların temini ve geri verilmesi, ve hataların çevirimi gibi işleri de yürütmektedir.
Bu tarafta meydana gelebilecek arızalar mesajların kaybolmasına veya yanlış biçimde teslimine, vazifeli thread’larin kaybolmasına veya atomik olmayan mesaj işlemlerine yol açabilir.

Güvenlik Yönetimi

Güvenlik yönetimi için Spring Security (Acegi Security) kullanıldığı vakit, Spring çalışma zamanı yine pek çok uygulama bileşeninin işletim hattında yer almaktadır. Web katmanındaki filtreler kimliklendirme (authentication) ve yetkilendirme (authorization) işlerini yönlendirmektedir.
Çalışma zamanı aynı zamanda diğer uygulama katmanlarındaki güvenlik yönetiminden de sorumludur. Dekorasyon fazında ilgili interceptor nesneleri kaydedildikten sonra “secured” olarak tanımlanmış her operasyon bu “interceptor”ler tarafından “intercept” edilir. Çalışma zamanı, rol tabanlı erişimden ve ACL tabanlı güvenlikten de sorumludur. “Pre-invocation interceptor”ler o andaki kullanıcının ilgili metoda erişim yetkisinin olup olmadığını kontrol ederken, “post-invocation interceptor”ler operasyon sonucu dönen nesnelere aktif kullanıcının erişim hakkı olup olmadığını denetler.
Güvenlik altyapısında meydana gelebilecek arızalar sistemdeki kaynaklara ve operasyonlara yetkisiz erişim, yanlış yetkilendirme, ve kimliklendirme sürecinde başarısızlık şeklinde kendini gösterecektir.

JMX Entegrasyonu

Spring, herhangi bir MBean nesnesini veya normal bir uygulama bileşenini JMX’e dahil etmeyi oldukça kolay kılmaktadır. JMX alt sistemi, mevcut herhangi bir MBean veya MXBean nesnesini bir MBean sunucusuna (MBeanServer) kayıt ettirebilir. Herhangi bir yönetim arayüzüne sahip olmayan normal uygulama bileşenlerinin bu sunuculara kayıt işlemi de oldukça kolaydır. JMX alt sistemi bu tür bileşenler için çalışma zamanında otomatik olarak ModelMBean nesneleri oluşturmaktadır. Spring’in JMX desteği, uygulama hakkındaki operasyonel bilginin JMX vasıtası ile erişilebilir kılınması için oldukça kolay bir yoldur.

WEB İstekleri

Spring çalışma zamanının web isteklerinin işlenmesine müdahil olması kullanılan “web framework”üne göre değişmektedir. Spring, istek(request) ve oturum(session) kapsama alanındaki bileşenleri her zaman yönetmektedir. Böyle bir bileşen üzerinde herhangi bir operasyon çağırıldığı vakit, gerekiyorsa yeni bir nesnenin oluşturulması ve isteğin doğru bileşene sevk edilmesi sağlanır. Spring çalışma zamanı genellikle web sayfasındaki verinin alan nesnelerine bağlanması (data binding) ve verinin doğrulanması (validation) işlemlerinde de görev almaktadır. Pek çok yeni nesil web uygulaması Spring Web Flow üzerine bina edilmektedir. Spring Web Flow, web uygulamalarındaki akışları ve bu akışlar arasındaki geçişleri yöneten önemli bir bileşendir.
Web altyapısındaki arızalar yanlış veya güncel olmayan (stale) bir bilgiye erişilmesine, yada bilginin kaybolmasına neden olabilir, girdinin uygulamadaki alan nesnelerine doğru biçimde dönüştürülememesine veya benzer durumlara yol açabilir.

Spring Çalışma Zamanı: Akort (Tuning)

Spring ile desteklenmiş bir uygulamanın performansını nasıl geliştirebilirsiniz?

Böyle bir uygulama üzerinde herhangi bir değişiklik yapmadan önce ilk yapılması gereken düşük performansın nedeni olabilecek noktaları belirlemek için ölçümleme yapmak ve önerilen değişikliklerin getireceği faydaları nicel olarak tespit etmektir. Bu aşamadan sonra optimizasyonlar iki temel kategoriye girmektedir:1. Etkin bir uygulama planının oluşturulması (uygulama konfigürasyonunun ve ayarların akortlanması), 2. Çalışma zamanındaki yeteneklerin etkin biçimde kullanılması (Uygulamanızın tasarımının optimize edilmesi).Uygulama geliştirmeye en açık ve temiz tasarımla başlayın, Spring’in sunduğu yetenekleri tam kapasite kullanın ve bunlardan farklı bir yola ancak rakamlar gerçekten bir fayda işaret ettiği vakit başvurun.

Önce Ölçümleyin

Herhangi bir akortlama çalışması için başlangıç noktası ölçümlemedir. Apache JMeter, Selenium gibi araçlar ve bir profiler burada faydalı olacaktır. Interface21 danışmanları JAMon ve Spring AOP yada AspectJ’yi bileşenler üzerindeki işlemleri ve isteklerin işletim yollarını incelemek için birleştirmede başarılı sonuçlar almışlardır.
Katmanlara göre ayrı ayrı ölçümleme yapın ki, örneğin web katmanında içeriğin gösterimi için harcanan zamanla, herhangi bir başka katman ve onun daha aşağısında geçen zaman arasında bir kıyas yapabilesiniz.

Etkin Bir Uygulama Planı (Blueprint) Oluşturun

Etkin bir uygulama planı oluşturmanın sırrı sisteminizin kurulacağı hedef platformun bütün avantajlarını kullanmaya çalışmaktır. Bunu gerçekleştirmek Spring’in ortamsal bağımlılıkları uygulama kodunuzun dışında tutmasından ötürü eskiye nazaran çok daha kolaydır.

Eğer bir uygulama sunucu üzerinde çalışıyorsanız sistemin yönetim arayüzü üzerinden oluşturulmuş veritabanı bağlantı havuzunu kullanabilirsiniz. Spring’i, bu havuzun referansına JNDI üzerinden erişecek biçimde ayarlayabilirsiniz. Örneğin,

	
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
    <property name="driverClass" value="${jdbc.driverClass"/>
    <property name="jdbcUrl" value="${jdbc.url}"/>
    <property name="user" value="${jdbc.username}"/>
    <property name="password" value="${jdbc.password}"/>
</bean>

yukarıdaki dataSource bileşen tanımını kullanmak yerine aşağıdaki tanımı kullanmanız daha doğru olacaktır.

<jee:jndi-lookup id="dataSource" jndi-name="jdbc/MyDataSource"/>

Yukarıdaki tanımı kullanmanız size iki avantaj sağlayacaktır: Birincisi uygulamanın bakımını uygulama sunucusu yönetim arayüzünden yapmak operasyonel ekipler için daha kolay olacaktır. İkincisi ise uygulama sunucu üreticisi bağlantı havuzunu pek muhtemelen kendi platformu için optimize etmiştir.
Aynı şekilde, JMS ile çalışırken de uygulama sunucusu üzerinde ayarlanmış JMS ConnectionFactory ve Destination nesnelerine JNDI ile erişmeniz daha doğru olacaktır. Burada ilaveten uygulama sunucusunun ConnectionFactory nesnesi sadece JMS bağlantıları için değil, diğer ara katman JMS kaynakları için de, örneğin oturumlar ve mesaj üreticiler gibi, havuzlama yapıyor olacaktır. Bu diğer JMS kaynaklarının da havuzlanması ile JMS sağlayıcının en yüksek debisine erişmeniz daha büyük bir ihtimaldir. Bu kaynakların yönetilmediği bir Java EE ortamında ise Spring’in SingleConnectionFactory nesnesi aynı bağlantıyı tekrar tekrar kullanacaktır. Eğer üreticiniz havuzlama kabiliyetine sahip bir ConnectionFactory nesnesi sağlıyorsa bunun avantajlarından sonuna kadar yararlanmanız en doğrusu olacaktır. Bu JmsTemplate kullanarak mesaj gönderme sırasında ortaya çıkabilecek en büyük performans darboğazını ortadan kaldıracaktır.
Transaction yönetimi için eğer Spring sizin kurulum ortamınız için özel bir platform transaction yöneticisine sahip ise mutlaka bunu kullandığınızdan emin olun. Örneğin, Spring WebLogic tarafından geliştirilen transaction ortamının avantajlarını tam manası ile kullanabilmeyi sağlayan WebLogicJtaTransactionManager bileşenini sunmaktadır. Aynı şekilde WebSphere için WebSphereUowTransactionManager ve OC4J için de Oc4jJtaTransactionManager bileşenleri mevcuttur. Eğer bu ortmalardan birine kurulum yapıyorsanız, standart JtaTransactionManager bileşeni yerine bunlardan birini tercih etmelisiniz. Spring 2.5 ile birlikte gelen elemanı mevcut ortamı otomatik olarak algılayıp uygun bileşeni seçecektir.
Sunucu üzerinde ayarlanmış bileşenleri JNDI vasıtası ile kullanmak kurulum ortamınızın imkanlarından tam kapasite yararlanmanızı sağlayacaktır. Bununla birlikte, hala uygulama sunucusu dışında da entegrasyon testlerinizi çalışırabiliyor olmalısınız. Örneğin, ActiveMQ’yu kullanarak mesajlaşma ile ilgili basit bazı entegrasyon testleri çalıştırmak, fakat sisteminizi IBM MQSeries ile kurmak isteyebilirsiniz. Bu tür ayarlamalar Spring’in birden fazla ayar dosya desteği ile kolaylıkla gerçekleştirilebilir. Ortama bağlı her türlü ayar bilgisini uygulamanın ana ayar bilgilerinden ayrı tutmanızı öneririz. İyi pratiklerden biri, her bir uygulama modülü için ayrı bir ayar dosyası oluşturmaktır. Bunlara ilave olarak, örneğin integration-test.xml veya production.xml gibi bir ayar dosyaları da oluşturabilirsiniz. Entegrasyon testleri sırasında diğer uygulama modüllerinin ayar dosyaları ile birlikte integration-text.xml dosyasını kullanarak, üretim ve sistem testleri sırasında da bu dosyayı production.xml dosyası ile değiştirerek bir uygulama bağlamı (application context) oluşturabilirsiniz.
Spring’in PropertyPlaceholderConfigurer bileşeni ayar bilgilerinin operasyonel ekiplerin müdahale edebilmesini sağlayacak biçimde ayar dosyalarından dışarı çekilebilmesi için güzel bir çözümdür. Interface21 danışmanlarının başarılı biçimde uyguladıkları bir yöntem properties dosyalarını aşağıdaki gibi zincirlemeye tabi tutmaktır:

classpath*:*.properties.local: Bu properties dosyaları kaynak kod yönetim sistemine dahil edilmeyip, yazılım geliştiricilerin mevcut ayarları kendi ortamlarına göre değiştirebilmelerini sağlar.
classpath*:META-INF/*.properties.default: Bu properties dosyaları kurulum sırasında üretilen uygulama ara ürünlerine dahildir ve varsayılan ayarları barındırmaktadır. Bazen proje ihtiyaçlarına göre bu kısım göz ardı edilebilir.
classpath*:*.properties: Bu properties dosyaları herhangi bir uygulama ara ürününe dahil değildir ve operasyonel ekiplerin ayarları kolayca değiştirmesini sağlar.

<context:property-placeholder location="classpath*:META-INF/*.properties.default,classpath*:*.properties,classpath*:*.properties.local"/>

Burası için güzel bir ip ucu da Spring’in JMX desteğini kullanarak bir MBean oluşturup bütün ayar bilgilerini JMX vasıtası ile dışarıdan erişilebilir kılmak olabilir. Bu sayede çalışan bir uygulamaya bağlanarak kolaylıkla o anda kullanılan ayar bilgilerinin neler olduğunu görebilirsiniz.

Bütün bunlara ek olarak etikin bir uygulama planı oluşturmak için üzerinde düşünülmesi gereken diğer noktalar şöyle sıralanabilir:

Kullandığınız JDBC bağlantı havuzu için en uygun bağlantı sayısını tespit edin. Bu aşamada gerçekçi bir üretim durumu senaryosu kullandığınızdan emin olun.
Spring’in TaskExecutor yapısını bir thread havuzu ile beraber kullanıyorsanız uygun bir thread havuz büyüklüğü belirleyin. İşlem yoğun işler için CPU sayısına denk miktarda thread iyi bir başlangıç olabilir. Eğer işleriniz yerel dosya sistemine erişip I/O gerçekleştiriyorsa bir thread ekleyin. Ağ üzerindeki I/O işlemleri için birden fazla thread ekleyin. TaskExecutor yapısını WebSphere veya WebLogic üzerinde kullanıyorsanız mevcut ortamın avantajlarından yararlanmak için (örneğin, kendi kendini akortlayan havuzlar) ve entegrasyon amacı ile CommonJWorkManagerTaskExecutor sınıfını kullanın.
Transaction demarcation ayarları yapılırken salt-okunur transactionlar için salt-okunur özelliği kullanın. Bu ayar Hibernate kullanılan, veritabanından pek çok nesnenin okunduğu fakat herhangi bir değişikliğin yapılmadığı transactionlar için ciddi bir performans artışı sağlayacaktır. Salt-okunur özelliğin aktive edilmesi Hibernate oturumunun FlushMode.NEVER’a set edilmesini sağlayacaktır. Bu da Hibernate oturumundaki nesnelerin oturum sonlandırılırken herhangi bir değişiklik yapılıp yapılmadığına yönelik kontrole tabi tutulmaması demektir.
2-PC ihtiyacınız yoksa (tek bir kaynak yöneticisi sözkonusu ise) yerel transaction yöneticisi kullanın. Spring, HibernateTransactionManager’ı kullanarak JDBC ve Hibernate ile gerçekleştirilen veri erişimlerini aynı transaction içinde kolaylıkla kontrol edebilir. Bu birden fazla erişim modunun, fakat sadece bir kaynak yöneticisinin kullanılması durumuna denk düşmektedir.
Message listener container’lar için kurulum ortamının JMS transaction’larını “acknowledge=transacted” özelliğini set ederek kullanın.

Çalışma Ortamının Optimizasyonlarından Yararlanın

Pek çok kurumsal uygulamanın performans problemleri persistence katmanına dayanır. Bu tür uygulamalardaki iyi performans, sıklıkla sağlam tasarım kararlarının bir sonucudur. Bu durumlar için bazı faydalı ipuçları şöyle sıralanabilir:

ORM aracı kullanırken “eager” ve “lazy” yükleme startejilerini uygun dengeli biçimde kullanmaya özen gösterin. Varsayılan özellik olarak “lazy” yüklemeyi kullanın, daha sonra “eager” yüklemeden faydalanabilecek durumları akortlamak için “fetch join”leri kullanın. Sorguları akortlarken “şu andan itibaren üretim hattında 1 sene” boyunca ihtiyaçları karşılayabilecek şekilde akortlama yapın.
ORM aracınızın veya veritabanının imkanlarından yararlanarak SQL ifadelerini log’larınıza basın. Bu şekilde ne zaman çok fazla sorgunun işletildiğini tespit etmeniz gayet kolay olacaktır.
Hibernate kullanıyorsanız Hibernate Statistics nesnesinden çalışma zamanında neler döndüğünü anlamak için yararlanın. Statistics nesnesine, program kodu içerisinden veya bu nesneyi Spring kullanarak MBean sunucusuna MBean olarak kayıt ettirerek erişebilirsiniz. Statistics nesnesini JUnit testleri ile birlikte programatik olarak kullanabilir, kaç tane sorgu çalıştırılacağını sınayıp, en fazla kaç sorguya tolerans gösterebileceğinizi belirleyebilirsiniz.
Toplu işlemlerde, toplu ekleme veya güncelleme gibi, ve saklı yordamlarda ORM yerine JDBC’yi (Spring JDBC aracılığı ile) kullanmanız en doğrusudur. Spring Hibernate ve JDBC veri erişim yöntemlerinin aynı transaction içerisinde beraber kullanılmasını oldukça kolaylaştırmaktadır. Sadece aynı tablolar üzerinde çalışıyorsanız doğrudan JDBC ile çalışmaya başlamadan evvel Hibernate oturumunuzu boşalttığınızdan (flush) emin olmanız yeterlidir.
Veritabanınızın sağladığı olanakları en üst düzeyde kullandığınızdan emin olunuz.
- Bir uygulamada çok büyük bir excel dosyasını okuyup, kayıtları basit bir dönüşüme tabi tuttuktan sonra SQL Server’daki bir tabloya eklememiz gerekiyordu. En iyi akortlama gayretimize rağmen bu işlem 3 saati buluyordu. SQL Server’ın “linked” sorgu kabiliyetinden yararlanıp, Excel dosyasını ODBC ile erişilen bir veri kaynağı gibi ele aldığımızda ve dönüşümle ilgili iş mantığını da saklı yordama taşıdığımızda süre sadece 17 sn’ye düşmüştü.
- Derinliği belirsiz bir ağaç yapısı üzerinden dolaşma ihtiyacı olan başka bir uygulama ise Hibernate ile yazılmıştı. En iyi çabalarımıza rağmen sorgu saatler sürüyor ve sonunda “Out Of Memory” hatası alınıyordu. Oracle saklı yordamları ve hiyerarşik sorgu desteği ile bu işlem 5 sn altında tamamlanmıştı.
- Eğer normal bir dosyayı Oracle veritabanına yüklemeniz gerekiyorsa veriyi Oracle’ın SQL Loader’ı ile ara bir tabloya attıktan sonra bir saklı yordam ile bu tablodaki veriyi işleyip asıl tablolara transfer edebilirsiniz.
Eğer bir operasyon tamamen persistence mantığından oluşuyorsa (başka bir deyişle herhangi bir iş mantığı içermiyorsa) bu durumda onu bir saklı yordama taşımayı ve bu saklı yordamı da Spring JDBC ile çağırmayı düşünebilirsiniz.
Salt okunur referans veriyi ön bellekte tutulabilirsiniz.

Toplu işlem (batch) uygulamalarda bellek kullanımı çok önemli bir unsur olduğundan bu konuya ayrıca dikkat etmek gerekmektedir. Sonuç olarak çok fazla miktarda bellek tüketip, maliyeti yüksek “garbage collection” duraklamalarından kaçınmanız gerekecektir. “Stream” tabanlı algoritmalar bu tür uygulamalar için en uygun yaklaşımdır. Örneğin, bu türr uygulamalarda “collection”lar yerine “iterator”ları kullanmalısınız. Eğer satırları bölmek istiyorsanız karakter tabanlı bölümlemeyi “String” tabanlı bölümlemeye tercih etmelisiniz. Bu yaklaşımı kullanarak 2.5 milyon satırlık bir dosyayı sadece 120K’lık bir bellek kullanarak 4 sn’nin de altında bir sürede okuyup, yorumlayıp, işlemeyi başardık.
XML kullanılan toplu işlem uygulamaları için de “stream” yaklaşımı uygundur. Daha önceki bir uygulamada 280 MB’lık bir dosyada 100,000 karmaşık XML olayını işleme durumu ile karşı karşıya kaldık. Bu işlem DOM tabanlı yaklaşımda, her olay için bir DOM ağacı oluşturularak gerçekleştirildiğinde 2.5 saat sürüyor ve 9 dk’ya varan “garbage collection” beklemelerine neden oluyordu. XML “pull” tabanlı bir yorumlamaya dönerek bütün girdiyi sadece 200 K’lık bir bellek ile 3 sn’de işlemeyi başardık.
Burada başka bir faydalı ipucu da birim ve entegrasyon testleri sırasında java.lang.management paketindeki JVM istatistiklerini kullanmaya çalışmaktır. Bu yöntem size CPU ve “garbage collection” zamanı vs. ile ilgili kontroller yapabilmeyi sağlar.
Son bir öneri de veri katmanınızı akortlama ile ilgilidir. Her takım elinin altında iyi bir DBA’ya sahip olmaktan faydalanacaktır.
Interface21 danışmanları tarafından derlenen çalışma zamanı akortlaması ve optimizasyonları ile ilgili öneriler şöyle sıralanabilir:

Spring Batch projesindeki tekrar deneme desteği, başarısız sonuçlanan operasyonları tekrar denemek için kullanılabilir. Bu yöntem son kullanıcılara yansıyan arızaların sayısını azaltarak operasyonel yükü hafifletebilir.
Web içeriğinin üretilmesinin (render) maliyetini hafife almayın. Bu işlemi kesinlike bir transaction dışında gerçekleştirmelisiniz.
Her web isteği için tekrar tekrar uygulama bağlamı (application context) oluşturmayın. (Legacy uygulamaları Spring’e taşırken zaman zaman karşılaşılan bir durumdur.)
Arka planda çalıştırılabilecek işlerde kullanıcı bekleme zamanını azaltmak için Spring’in asenkron “task executor”unu kullanmayı düşünün.
Uygun bir “remoting” protokolünü tercih edin. SOAP ile birlikte çalışabilirlik ihtiyacınız yoksa, Spring’in HttpInvoker desteği basit bir durum için daha basit ve hızlı olacaktır.
Uygulamanızın geniş bir bölümünü etkileyen “aspect”ler varsa bunları çalıştırmak içim Spring AOP yerine AspectJ kullanmayı düşünün.

Interface21 danışmanlarının akortlama ile ilgili faydalı buldukları bazı kaynaklar:

Thomas Kyte’ın “Runstats.sql” test harness
“Effective Oracle by Design” (Thomas Kyte)
“Java Performance Tuning (Jack Shirazi)
Sun Java Performance Guides

Özet

Spring çalışma ortamı uygulama bileşenleri için kapsamlı bir servis seti sunmaktadır ve üretim hattında uygulamaların çalıştırılmasında kritik bir rol oynamaktadır. Bu servisler çekirdek uygulama bileşen yönetimi, transaction’lar, güvenlik, veri erişimi vb. içermektedir.

Bu makale operasyonel ekiplere Spring uygulamalarının çalışma zamanındaki davranışlarını daha iyi anlamaya, ve olabilecek aksaklıkları gidermeye yönelik bir kılavuzluk sağlamaktadır. Spring destekli bir uygulamayı akortlama ile karşı karşıya kaldığımızda yapılması gerekenler ilk önce ölçümleme, ardından etikin bir uygulama planı oluşturma ve son olarak da etkin bir tasarım ile çalışma ortamının optimizasyonlarından faydalanmaktır.
Çalışma zamanındaki servislerin düzgün bir fonksiyonaliteye (hatta çalışır bir fonksiyonaliteye) sahip olmasının hayatiyet arz eden niteliği dikkate alındığında, Spring yüksek standartlarda bir mühendislik ürünü olup, kalitesi ile ilgili sağlam bir üne sahiptir. Dünya genelindeki binlerce Spring destekli uygulama bunun bir kanıtıdır.

Teşekkür ve Bilgilendirme

Pek çok Interface 21 çalışanına bu makale için akortlama ile ilgili verdikleri ip uçları ve öğütler için teşekkürler.

Java ve JMX, ABD ve diğer ülkelerde Sun Microsystems’in tescilli markasıdır.

OSGI ABD ve diğer ülkelerde OSGI Alliance’ın tescilli markasıdır.

IBM, MQSeries, ve WebSphere, ABD ve diğer ülkelerde IBM’in tescilli markasıdır.

Oracle, Oracle Corporation ve ortaklarının tescilli markasıdır.

Atıflar

Apache JMeter – http://jakarta.apache.org/jmeter/
JAMon – http://jamonapi.sourceforge.net/
Selenium – http://www.openqa.org/selenium/
Runstats.sql (Thomas Kyte) – http://asktom.oracle.com/tkyte/runstats.html
“Java Performance Tuning”, Jack Shirazi
“Effective Oracle by Design”, Thomas Kyte
Java performance guides http://java.sun.com/docs/performance/

Kenan Sevindik