Magento Otomatik Önbellekleme Bilgisi

Memcache ile Magento EE 1.11 kullanıyoruz. Memcahce sunucusu başına 2GB, toplam 4GB. Yaklaşık 240k ürünümüz var.

• Mevcut ram: 6GB
• Çekirdekler: 16
• Konular: 32

İşte anlaşma, daha fazla yeni ürün ekleniyor ve ürünlerde değişiklikler günlük olarak gerçekleşiyor ve elbette arka uçta her yeni ürün eklendiğinde / değiştirildiğinde, önbellek geçersiz kılınıyor, özellikle 'Tam Sayfa Önbelleği'.

Magentos Otomatik Önbellek Üretimi etkinleştirildiğinde, önbelleğin oluşturulması yaklaşık 2 gün sürer ve tarayıcıya 8 iş parçacığı tahsis edilir. 2 gün sonra memcache iki ram diski arasında ayrılmış ~ 2GB civarında yüzer.

Sorun, ürünler günlük olarak değiştirildiğinde önbellek geçersiz hale gelir ve 'Tam Sayfa Önbellek' yenilendiğinde bu 2GB önbellek bir, 0 kareye geri döner ve Magentos Auto önbelleğinin viskoz döngüsü yeniden başlar. Şimdi, sadece önbellek 0'a geri dönmekle kalmıyor, aynı zamanda CPU kullanımı% 90'a çıkıyor ve web sitesi 5-10 + saniyelik bir bekleme oyununa dönüşüyor ve eğer 100+ varyasyon ile bir ürün talep etmeyi unutabilirsiniz, eğer önbelleğe alınmamış ilk kez yüklemek dakikalar sürebilir, çok saçma.

Yani, topluma sorularım.

• Magento'nun geçersiz kılınmışsa tüm önbelleği yeniden oluşturmadan ve 0'dan başlayarak önbelleği otomatik olarak "güncellemesinin" bir yolu var mı? Önbelleğin ne zaman geçersiz olduğunu Magento'nun bir şeylerin değiştiğini bildiğini biliyorum, ama tam olarak önbellekte nerede olduğunu (yanlışsam beni düzeltin). Tüm önbelleği yeniden oluşturmayı atlamak için orada modüller / yapılandırmalar var mı?

Yan notta, Tiny Bricks LightSpeed ​​modülünü kullanıyoruz.

• Magentos Otomatik Önbellek Üretimi zaman bir cronjob ile kontrol edilebilir mi? Diyelim ki, 10: 00-18: 00 saatleri arasında taramaya başlayın.

• Bu duruma yaklaşmanın en iyi yolu nedir ?, Anladığınız gibi, her gün gigabayt cinsinden bir önbelleği yeniden oluşturmak kabul edilemez.

Neredeyse yeterli RAM'iniz yok

240k kadar ürünümüz
mevcut Koç: 6GB
Konular: 32

Sahip olduğunuz ürün miktarı için neredeyse yeterli RAM'iniz yok. Genel bir kural olarak, mantıksal çekirdek başına en az 2-4GB RAM öneriyoruz.

Olası bellek kullanımınızın haritasını çıkarırsanız:

• max_memory~ 768MB = 24GB arası 64 PHP İş Parçacığı
• 240.000 Ürün muhtemelen 15GB InnoDB tablo alanı anlamına gelecektir
• 64 PHP İş Parçacığı 128 MySQL bağlantısı hakkında garanti verir, bu genellikle bağlantı başına minimum 200 MB maliyetle gelir
• Redis ve lzfsıkıştırılmış 240.000 ürün için arka uç depolama alanı - yine de yaklaşık 6GB RAM tüketecek

Şimdiye kadarki toplam 70GB kararlı RAM - işletim sisteminden vb. Bahsetmedik bile.

Donanımınız korkunç bir şekilde yetersiz . Bu Magento sunucusu kurmak için nasıl ilerleme hakkında bir feeler biraz makale okumak öneririz .

Memcached önbellek etiketlerini desteklemez

Memcached kullanıyorsanız (sorun değil, çok yüksek performansı), önbellek etiketlerini depolarsınız veya saklamazsınız. slow_backendTanımlanmış bir etiketiniz yoksa, etiketleri saklamıyorsunuz, bu da temel olarak önbelleğinizin farklı önbellek türleri arasında ayrım yapamayacağı anlamına gelir - böylece bunları bağımsız olarak temizleyemezsiniz.

Bunu okuyun, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Redis'e geçmenizi şiddetle tavsiye ederiz. Tuhaflıkları var ve daha büyük mağazalar için önemli ince ayar gerektiriyor. Ancak bir bütün olarak, önbellek etiketi desteğinin gerçek faydası ile Memcached'den biraz daha iyi performans gösterecektir.

404'ler ve FPC

FPC'nin gerçek bir sorunu var, aslında, tüm önbellek motorlarının 404'lerde bir sorunu var. Bunun nedeni, hala taranan veya bağlanan eski URL'ler, tüm core_url_rewritetabloyu yinelemek , sonunda 404'ten vazgeçip yüklemeden önce tüm tanımlanmış yönlendiriciler ve ad alanlarıyla eşleşmek zorunda kalan bir sayfaya gelecektir .

Ardından, değeri olmayan ve önbellek depolama alanınızda yer kaplayacak bir kaynağı önbelleğe alma. Muhtemelen Memcached depolamanızın büyük bir bölümünün aslında 404 içerik tarafından yenildiğini göreceksiniz.

Büyük kataloglarda (240 bin ürün), kesinlikle ürün cirosundan ve dolayısıyla URL'lerde ve daha sonra 404'lerde değişikliklerden adil bir pay alacaksınız.

FPC Geçersiz ve Temiz

Şu anda - ve varsayılan olarak - FPC'nin davranışı, yalnızca önbellek girişini geçersiz kılmak yerine önbellek değişikliklerinde temizlemektir. Bir EE mağazasının tam olarak istediğinizi yapması için bu davranışı değiştirmek için bir uzantı yazdık.

İşte size sorununuzu nasıl çözeceğiniz hakkında bir fikir vermek için hızlı bir yama.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Tarayıcı çalıştırmayın

Yeterince iyi bir ayağınız varsa - tarama aracını çalıştırmanızı önermiyoruz, gereksiz yük oluşturur. Siteye göz atan kullanıcılar / botlar / tarayıcılar önbelleği hazır bulundurmalıdır.

Ancak sorunuzu cevaplamak için, yukarıda belirtilen yapılandırma dosyasına bakarsanız, tarama tarama penceresi için tanımlanan cron zamanlamasını görürsünüz.

Eski içerik alabiliyorsanız

Ve sonuç olarak, yeterli RAM'iniz varsa. Önbelleğe alınan verilerinizi daha uzun süre canlı tutmak için FPC'de depolanan içeriğin TTL'sini artırmanın avantajlarından yararlanabilirsiniz.

In <full_page_cache>etiketinin senin ./app/etc/local.xmlsadece tanımlamak

<lifetimelimit>86400</lifetimelimit>

Kullanım ömrü saniye olarak tanımlanır. İçerik tazeliği, performans ve gerçekte sahip olduğunuz depolama alanı miktarı arasında bir denge kurmanız gerekir.

EE ile neden üçüncü taraf bir önbellek uzantısı kullanıyorsunuz?

FPC için bir prim ödüyorsunuz - ki bu beni çok üzüyor, çok iyi. Peki neden üstte üçüncü taraf alternatifleri kullanıyorsunuz. Onu kaldır.

Bu şekilde koy. Aracınız kötü çalışıyorsa - telafi etmek için bagajınıza başka bir motor eklersiniz; veya sadece oradaki motoru düzeltin mi?

Sizi çok iyi anlıyoruz! Her gün yeni ürünler ekliyor veya ürünlerimizi değiştiriyoruz ve statik blokları da değiştiriyoruz. Bu yüzden, geçersiz Magento önbelleği ile doluyduk ve bu sabit Sistem -> Önbellek Yönetimi'ne gidiyor. Geçersiz kılınan önbellek türlerini manuel olarak yenileme gerekliliğinden nefret ettik.

Sonra yeni Magento Optimizer uzantısı kurduk . Bu modül bu işlemi otomatikleştirir. Geçersiz / tüm önbellek türlerini yeniler veya Magento önbellek depolamasını belirtilen sıklıkta temizler. Tüm ekibimiz için gerçek bir rahatlama oldu!

Bu uzantının bir diğer harika özelliği, X günden daha eski oturum dosyalarını ve hata raporlarını temizlemesidir. Herkes var / session ve var / report dizinlerinin boyutunun gigabayta dönüşebileceğini ve bu dosya sayısının yüzün üzerine çıkabileceğini biliyor. Web sitesi performansını yavaşlatmak için Magento Optimizer'ı bir kez ayarladık ve bu dizinlerin periyodik olarak yenilenmesini unuttuk.

Magento, müşteriler giriş yapmaya çalıştığında terk edilmiş bir arabayı mevcut sepetle birleştirmesiyle bilinir. Müşterilerin deneyimleri ve sadakat açısından bakıldığında bu yıkıcıdır. Magento Optimizer modülü, X gününden eski terk edilmiş arabaları otomatik olarak siler. Bu özelliği satış sırasında da kullanabilir ve mevcut terk edilmiş alışveriş sepetlerinin süresini sınırlayabilirsiniz.