SAP Commerce (Hybris) Performans Rehberi

Hybris'te performans sorunu nereden başlar?

SAP Commerce projelerinde performans şikâyetlerinin büyük bölümü platformdan değil, platformun güçlü araçlarının disiplinsiz kullanımından doğar: kontrolsüz FlexibleSearch sorguları, ayarlanmamış önbellek bölgeleri, her şeyi indeksleyen Solr yapılandırmaları ve mesai saatinde çalışan ağır cronjob'lar. Bu yazı, şikâyetten köke inen katmanlı bir teşhis ve iyileştirme metodolojisi sunar.

Teşhis önce: ölçmeden ayar yapılmaz

İlk adım her zaman görünürlüktür: yavaş sayfa mı, yavaş sorgu mu, yavaş entegrasyon mu? Uygulama izleme (APM) ile isteklerin katman kırılımı; veritabanı tarafında yavaş sorgu logları; Hybris tarafında sorgu ve önbellek istatistikleri birlikte okunur. "En yavaş 10 istek + en sık 10 sorgu" listesi, çoğu projede iyileştirme sırasını tek başına belirler. Ölçüm olmadan yapılan her ayar, tahmindir.

Katman katman: belirti → kök neden → önlem

Katman	Tipik belirti	Öncelikli önlem
FlexibleSearch	DB CPU yüksek; aynı sorgu binlerce kez	N+1 temizliği, alan seçimli sorgu, sayfalama
Önbellek	Düşük isabet oranı; sık tahliye	Bölge boyutlarının tip profiline göre ayarı
Solr	Arama gecikmesi; uzun tam indeksleme	İndekslenen alan diyeti; artımlı indeks stratejisi
Cronjob	Belirli saatlerde genel yavaşlama	Yoğun saat dışına planlama; ayrı düğüm
JVM/GC	Periyodik duraklamalar	Heap ve GC'nin yüke göre yapılandırılması
Ön yüz/CDN	Sunucu hızlı, sayfa yavaş	Medya CDN'i, sayfa parça önbelleği

FlexibleSearch disiplini: en büyük kazanım burada

Üç kural çoğu sorunu çözer. Birincisi N+1'in avlanmasıdır: liste ekranında her satır için ayrı sorgu üreten servis kodu, tek toplu sorguya çevrilir. İkincisi alan seçimidir: yalnızca PK'sı veya birkaç alanı gereken yerde tam model hidrasyonu yerine alan döndüren sorgular kullanılır — model doldurma, hem sorgu hem önbellek maliyetidir. Üçüncüsü sayfalamadır: sınırsız sonuç döndüren sorgu, bugün küçük olan katalogda yarın olay çıkarır. Bu kuralların kalıcı olması için kod incelemesine 'sorgu başına maliyet' sorusu eklenir ve yavaş sorgu logu düzenli taranır.

Önbellek: boyut değil, profil ayarı

Hybris'in bölge önbelleği (region cache), tip bazında ayrılabilir alanlardan oluşur; varsayılan boyutlar her katalog profiline uymaz. Doğru yaklaşım isabet/tahliye istatistiklerinin izlenmesi ve en çok okunan tiplerin (ürün, fiyat, stok, kategori) bölgelerinin bu veriye göre boyutlandırılmasıdır. İkinci başlık geçersiz kılmadır (invalidation): kümedeki düğümler arası geçersiz kılma trafiği, yazma-yoğun senaryolarda kendisi bir yük kaynağı olabilir — toplu içe aktarmaların önbellek davranışı planlanmalı, dev importlar mümkünse bakım pencerelerine alınmalıdır.

Solr: indeks diyeti ve artımlı strateji

Arama performansının iki düşmanı vardır: her özniteliği indekslemek ve her değişiklikte tam indeks koşturmak. İlki için indekslenen alan listesi iş gereksinimiyle sınırlanır — aranmayan, filtrelenmeyen, listelenmeyen alan indekste yer almaz. İkincisi için artımlı (update) indeksleme ana yol olur; tam indeksleme, düşük trafik penceresine planlanır ve süresi bir metrik olarak izlenir. Sorgu tarafında facet sayısı ve boost karmaşıklığı da gecikmeye doğrudan yansır; arama deneyimi tasarımı ile performans birlikte düşünülmelidir.

Cronjob ve entegrasyon planlaması

Gece koşması gereken işin gündüz koşması, en sık rastlanan 'gizli' performans sorunudur. Cronjob envanteri çıkarılır; her işin süresi, kaynak profili ve çakışmaları görünür hale getirilir. Ağır işler (fiyat/stok içe aktarma, indeksleme, rapor) yoğun saat dışına ve mümkünse yalnızca arka plan işlerine ayrılmış düğümlere planlanır. Kuyruk tabanlı entegrasyonlarda geri basınç (backpressure) tanımlanır — kaynak sistemin ani yığını, storefront'un faturası olmamalıdır.

İş etkisi: hız, dönüşüm oranıdır

E-ticarette sayfa hızı ile dönüşüm arasındaki ilişki sektörde defalarca ölçülmüştür; yavaşlık doğrudan ciro kaybıdır ve arama motoru sıralamasını da etkiler. Teknik tarafta ise ölçüme dayalı optimizasyon, donanım büyütmeden — yani bulut faturasını şişirmeden — kapasite kazandırır. Performans çalışmasının çıktısı yalnızca hızlı sayfa değil; ölçüm altyapısı, sorgu disiplini ve planlama pratiği olarak kalıcı mühendislik kültürüdür.

Sık sorulan sorular

Önce donanım mı büyütelim, önce optimizasyon mu?

Önce ölçüm: darboğaz sorgu veya indekslemedeyse donanım parayı erteler, çözmez. Donanım, ölçümle doğrulanmış kapasite ihtiyacında anlamlıdır.

Her şeyi önbelleğe almak çözüm mü?

Hayır — yanlış boyutlanmış önbellek tahliye fırtınası ve bellek baskısı üretir. Önbellek, isabet istatistiğiyle yönetilen bir bütçedir.

CCv2'de bu ayarlar elimde mi?

Uygulama katmanı ayarlarının (sorgular, önbellek bölgeleri, indeks stratejisi, cronjob planı) tamamı sizin elinizdedir; altyapı boyutlandırması bulut yapılandırmasıyla yönetilir.

Yük testi ne zaman yapılmalı?

Büyük kampanya ve sürüm öncesi düzenli olarak; üretim benzeri veri hacmiyle. Küçük katalogla yapılan test, üretim davranışını temsil etmez.

Performans kontrol listesi

APM + yavaş sorgu logu + önbellek istatistikleri aktif
En yavaş istek/sorgu listesi düzenli raporlanıyor
N+1 taraması yapıldı; alan seçimli sorgular yaygın
Önbellek bölgeleri isabet verisiyle boyutlandırıldı
Solr alan diyeti uygulandı; artımlı indeks ana yol
Cronjob envanteri ve yoğun saat planı tanımlı
Kampanya öncesi yük testi süreci kurulu

SSH Yazılım, SAP Commerce (Hybris) projelerinde performans teşhisi ve optimizasyonunu ölçüme dayalı yürütür. Storefront'unuzun darboğaz haritasını birlikte çıkaralım.