Magento 2.4 performansı: Redis, Varnish, OPcache ve PHP-FPM ile önbellek yapılandırması

Magento altyapılı bir e-ticaret siteniz varsa büyük ihtimalle hız sorunu yaşamışsınızdır. Bu yazının ilk hâlini 2015'te, Magento 1 döneminde yazmıştım; Magento 2.4 ile önbellek altyapısı epey değişti. Konuyu yine e-ticaret sitesi sahiplerinin anlayacağı dilden, bu kez kendi yönettiğim mağazalarda ölçtüğüm örneklerle anlatacağım.

Bir e-ticaret sitesinde hız en önemli şeydir; evet, doğru duydunuz, belki güvenden bile önemlidir. Zor açılan bir site ne kadar güven verirse versin, müşterinin gözünde daha en başta olumsuz bir izlenim bırakır. Hele çok ürünlü bir mağazada arama, filtreleme ve sıralama ziyaretçiye eziyet ediyorsa satış yapmanız neredeyse imkânsızdır.

Performansı belirleyen üç şey

1. Donanım

Donanım bütçe meselesi, ama kısıtlı bütçede neyin önemli olduğunu bilmek gerekir. Magento 2.4'te en kritik kaynak bellek, çünkü PHP süreçleri, veritabanı, OpenSearch ve Redis aynı belleği paylaşır. Ardından SSD disk ve işlemci gelir. Asıl soru hâlâ aynı: aynı anda kaç ziyaretçiye hizmet vermeniz gerekiyor?

2. Kod: tema ve modüller

Magento kodu yazmanız gerekmiyor ama tema ve modül seçerken titiz davranın. Üreticinin ne kadar süredir Magento ürünü geliştirdiğine, güncelleme sıklığına ve destek kanallarına bakın; destek için size yalnızca bir e-posta adresi veren satıcıdan ürün almayın. Gereksiz modül kurmayın.

Tek bir modülün bütün siteyi nasıl yavaşlatabileceğine dair kendi örneğim: bir mağazada analitik amaçlı bir modül, her sayfada yüklenen genel düzen dosyasına (default.xml) cacheable="false" işaretli bir blok ekliyordu. Magento'da tek bir blok önbelleklenemez işaretlenirse o sayfanın tamamı önbellek dışında kalır; blok her sayfada olduğu için de sitenin tamamı önbelleksiz çalışıyordu.

3. Önbellek

Önbelleği şöyle düşünebilirsiniz: ziyaretçiye, sütunlarında 10 marka, satırlarında 100 ürün özelliği olan bir karşılaştırma tablosu sunacağız. Bu tablo için veritabanından 1.000 ayrı bilgi okunup yerine yerleştirilmeli. Bu iş zaman alır, ziyaretçi ise beklemek istemez. Önbellek, tabloyu bir kez hazırlayıp saklar ve sonraki ziyaretçiye hazır sonucu verir. İşin zor tarafı neyin ne zaman geçersiz sayılacağına doğru karar vermektir; Magento 2 bunu katmanlar hâlinde yapıyor.

Magento 2.4'te önbellek katmanları

PHP: OPcache

2015'te APC, XCache ve eAccelerator gibi seçeneklerden söz etmiştim; hepsi tarihe karıştı. Bugün PHP'nin kendi OPcache'i kullanılıyor. Yukarıdaki mağazada OPcache'in hiç kurulu olmadığını da fark ettik; modül sorunuyla birlikte düzeltildiğinde sunucunun yanıt süresi 1,5–2,8 saniyeden yaklaşık 0,2 saniyeye indi. Adobe'nin performans önerilerindeki değerler iyi bir başlangıç noktası (sunucunuza göre ölçün):

opcache.enable=1
opcache.memory_consumption=512
opcache.max_accelerated_files=60000
opcache.save_comments=1
opcache.validate_timestamps=0

save_comments=1 Magento için zorunludur. validate_timestamps=0 ise PHP'nin dosya değişikliklerini hiç kontrol etmemesi demek: en hızlısı bu, ama her kod dağıtımından sonra PHP-FPM'i yeniden başlatmanız gerekir. Aksi hâlde komut satırı yeni kodu, web sitesi eski kodu çalıştırır. Bir kurulumda yapılandırma dosyasını değiştirdiğimiz hâlde sitenin eski veritabanına bağlanmaya devam etmesinin sebebi tam olarak buydu. Bu disipline hazır değilseniz validate_timestamps=1 ve revalidate_freq=2 makul bir uzlaşma.

Magento'nun kendi önbellekleri: Redis ya da Valkey

Yapılandırma, düzen (layout), HTML blokları gibi önbellek tipleri varsayılan olarak diske yazılır. Bunları, tam sayfa önbelleğini ve müşteri oturumlarını Redis'e taşımak hem hızlıdır hem de ileride birden fazla sunucuya büyümeye uygundur. Her biri ayrı bir veritabanı numarası kullanmalı:

bin/magento setup:config:set --cache-backend=redis --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0
bin/magento setup:config:set --page-cache=redis --page-cache-redis-server=127.0.0.1 --page-cache-redis-db=1
bin/magento setup:config:set --session-save=redis --session-save-redis-host=127.0.0.1 --session-save-redis-db=2

Adobe'nin güncel destek tablolarında son yama sürümleri için Redis yerine onunla uyumlu Valkey listeleniyor. 2.4.8 ve öncesinde Valkey'i de yukarıdaki redis parametreleriyle bağlıyorsunuz; 2.4.9'dan itibaren komutlarda valkey adı kullanılıyor.

İki pratik uyarı. Birincisi, yalnızca önbellek için kullanılan Redis'te diske kalıcı kayıt genellikle gereksiz: bir sunucuda Redis diske yazamadığı için bütün yazmaları durdurdu, bir başkasında yeniden başlatmada eski bir kayıt dosyasını yükleyip taşıma öncesi yapılandırmayı geri getirdi ve site hata vermeye başladı. İkincisi, oturumlar için eşzamanlı bağlantı sınırını (--session-save-redis-max-concurrency) trafiğinize göre ayarlayın; bir mağazada varsayılan sınır yüzünden hata kayıtları dolmuştu.

Tam sayfa önbelleği: yerleşik mi, Varnish mi?

Tam sayfa önbelleği, blokları değil sayfanın tamamını saklar ve hızın asıl kaynağıdır. Magento 2'de iki seçenek var: Redis'e yazan yerleşik önbellek ya da uygulamanın önünde duran Varnish. Adobe üretim ortamı için Varnish'i öneriyor; ama Varnish ayrı bir servis, ayrı bir yapılandırma ve SSL için önünde ayrı bir katman demek. Küçük ve orta ölçekli mağazalarda yerleşik önbelleğin Redis ile iyi sonuç verdiğini gördüm. Hangisini seçerseniz seçin, Mağazalar › Yapılandırma › Gelişmiş › Sistem › Tam Sayfa Önbelleği ayarının sunucuda gerçekten çalışan servisle uyuştuğundan emin olun.

Sepet ya da müşteri adı gibi kişiye özel bilgiler ne olacak? 2015'te "dinamik bloklar ayrıca tasarlanır" demiştim. Magento 2 bunu kendisi çözüyor: sayfanın herkese ortak kısmı önbellekten gelir, kişiye özel kısımlar sayfa yüklendikten sonra JavaScript ile ayrıca çekilir. Bu yüzden bir modülün bloğu önbellek dışı işaretlemesi neredeyse hiçbir zaman doğru çözüm değildir.

Veritabanı tarafında ise MySQL'in eski "query cache" özelliği MySQL 8 ile tamamen kaldırıldı; bu konuyu veritabanı optimizasyonu yazısında anlattım.

PHP-FPM: süreç sayısını bellek belirler

PHP-FPM aynı anda kaç PHP sürecinin çalışacağını belirler. Kural basit: PHP'ye ayırabildiğiniz bellek, bir sürecin gerçekte kullandığı ortalama belleğe bölünür. Bir kurulumda pm.max_children = 1000 ve memory_limit = 2G ayarlıydı. 16 GB'lık sunucu yoğun bir anda belleği tüketti, işletim sistemi önce PHP'yi sonra veritabanını kapattı ve izleme olmadığı için site günlerce kapalı kaldı. Değeri 25'e indirdiğimizde sunucu hem kararlı hem daha hızlı çalıştı.

; /etc/php-fpm.d/www.conf (örnek başlangıç noktası, sunucunuza göre ölçün)
pm = dynamic
pm.max_children = 25
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500

Ayrıca basit bir erişilebilirlik izlemesi kurun; kapanan bir mağazayı müşterinizden önce sizin fark etmeniz gerekir.

Doğru ölçmek

Hız konusunda en çok yanılgıyı yanlış ölçüm yaratıyor. Kendi yaşadığım üç tuzak:

• Tarayıcı önbelleği: tarayıcıda gördüğüm birkaç milisaniyelik yanıt, aslında tarayıcının kendi önbelleğiydi. Sunucuyu ölçmek için komut satırından istek atın.
• no-store başlığı: yerleşik tam sayfa önbelleği, sayfayı sunucuda saklarken tarayıcıya her zaman no-store der. Bunu arıza sanıp saatlerimi harcadım. Doğru ölçüt şu: önbellek temizlendikten sonra ilk istek yavaş, sonrakiler hızlı olmalı; Redis'teki sayfa anahtarı sayısı yeni sayfalarla birlikte artmalı.
• Mobili ayrıca ölçün: bir mağazada üçüncü parti bir blog modülü mobil cihazlar için önbellek anahtarını değiştiriyor, mobil sayfalar hiç önbellekten gelmiyordu. Masaüstünde yanıt 0,18 saniye civarındayken mobilde 1,1–1,3 saniyeydi; düzeltmeden sonra mobil de 0,16–0,21 saniyeye indi.

curl -s -o /dev/null -w '%{time_starttransfer}\n' https://magazaniz.com/
curl -s -o /dev/null -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' -w '%{time_starttransfer}\n' https://magazaniz.com/
redis-cli -n 1 dbsize

Sonuç

Sunucu hızlanınca iş bitmiyor; görseller, betikler ve stil dosyaları da sayfa hızını belirliyor. Mobil önbellek sorununu çözdüğümüz mağazada aynı gün görselleri WebP'ye çevirdik, otomatik kayan banner'ı ve gereksiz hâle gelmiş etiket yöneticisini kaldırdık; ana sayfanın mobil PageSpeed puanı 39'dan 95'e çıktı ve bu kazancın önemli bir kısmı ön yüzden geldi.

2015'te hız için ücretli, paketlenmiş çözümler öneriyordum. Bugün önerim farklı: Magento 2.4'ün kendi araçları, yani üretim modu, OPcache, Redis ve yerleşik önbellek ya da Varnish, doğru kurulduğunda fazlasıyla yeterli. Önemli olan ölçmek, her seferinde tek bir şeyi değiştirmek ve etkisini yeniden ölçmek.