1k - 10k web siteleri / mağazalarda performans sorunu


9

Web sitesi / mağaza miktarı 1k'yi aştığında ve hedefim 10k civarında olduğunda Magento performansını iyileştirmenin bir yolunu bulmaya çalışıyorum. İşte bazı sorular; herhangi bir ipucu / yardımcı olur son derece açıktır!

  1. Yeni web siteleri / mağazalar eklemek yavaştır;
    Ben Mage_Core_Model_Abstract içinde _afterSave () içinde $ this-> cleanModelCache () yorum ve durum daha iyi görünüyor ama artan sayıda web sitesi / mağaza ile yavaşlıyor. Ve bunun gelecekte tüm sistemi neyi etkileyeceğini bilmiyorum.

  2. Api çağrıları yavaşlar.
    Ana süreçlerden biri sipariş vermektir; özelleştirilmiş modelim, bazı verileri işleyerek ve esas olarak satış / teklif modelini ve satış / service_quote modellerini kullanarak ilgilenir. Süreç Oauth ile başlar. Web sitesi / mağaza sayısı arttıkça hem Oauth hem de sipariş verme daha uzun sürer ve bellek tüketimi daha büyük görünür. Bunun Mage'nin config xml dosyasını yüklemesiyle bir ilgisi var mı ve yapılandırma verilerinin artan web sitesi sayısıyla daha da artması mı?

  3. N98-magerun dev'in açılması: konsol daha uzun sürüyor; nedenini bilmiyorum.

  4. Yönetici panelinden yapılandırmanın kaydedilmesi daha uzun sürer; nasıl geliştireceğini bilmiyorum.

Bellek tüketimini azaltmak için Magento'nun yapılandırma verilerini oluşturma ve yükleme şeklini yeniden yapılandırmak mümkün müdür? Bu durumum için performans sorununa neden olan faktörlerden biri mi?

Geçerli Magento örneği: Sürüm = Magento EE 1.14.2.4;
Önbelleği yapılandır; diğer önbellek kapalı;
Mysql 5.6 ve MongoDB'yi kullanma (catalog_category_entity, catalog_product_entity, core_website için);
web sitesi sayısı = mağaza sayısı = görüntüleme sayısı = 1024;
ürün sayısı = 4501;

Hepinize şimdiden teşekkürler!


2
neden magento destek size yardımcı olamaz ???
MagenX

Onlardan nasıl yardım alabilirim? Topluluğa yeniyim .. teşekkürler!
Jack.W

1
kurumsal sürümünüz var, nereden aldığınızdan emin değilsiniz, ancak arkasında magento desteği yoksa, sadece para ve zaman kaybettim. Onlara yardım eden tavşan gibi koşmak için toplara vurmalısınız. kurumsal sürüm sahip olmanın anlamı nedir ???
MagenX

1
ama sorgunuzun açık cevabı - 10-20 dükkandaki partiler gibi ayrı veritabanlarına sahip ayrı magento mağazaları ...
MagenX

Ah doğru .. Patronumdan hesap isteyeceğim .. haha.
Jack.W

Yanıtlar:


3

Yavaş olmasının nedenlerinden biri, her mağaza için yapılandırmanın / config / websitesinden ve / config / global'den çoğaltılması ve bunu yapmak için kodun en azından verimli olmamasıdır. Herhangi bir ayar değişikliği, saat olmasa da, performansın ve iş hacminin 10 dakikadan fazla olmamasına neden olabilir. Daha verimli hale getirmek, temelde Ben Marks'ın peşinizden geleceği anlamına gelir ... iyi bir şekilde değil.

Bu rotadan aşağı inecekseniz, en kolay yol 10 bin Magento kurulumuna sahip olmak ve ilgili web sitesine delegelerin taleplerini ileten bir tür komisyoncuya sahip olmak olacaktır. Tabii ki, gerçek kullanım durumunuzun ne olduğuna bağlı olacaktır.

[katma]

Kullanım durumuna bağlı olarak, kategorileri sözde mağazalar olarak kullanabilirsiniz. Daha sonra teknik olarak, mağaza başına temayı değiştirmek için düzen XML'sini kullanabilirsiniz. Ama sonra ödeme sınırlaması ile karşılaşacaksınız. Tüm mağazaların kasayı paylaşması gerekir.

Her iki durumda da, 10k Magento mağazaları mümkün değil, çünkü imkansız değil. Ama hangi yolu seçerseniz seçin zor bir yol olacaktır.


Merhaba Kevin, Cevabınız için teşekkürler! Evet yanlış değilse loadToXml () olan yapılandırma ağacını güncelleyen kodu görüyorum. Benim düşüncem; ve bunu değiştirmenin iyi bir fikir olmadığını mı söylediniz? Benden sonra gelen Ben Marks ile ne demek istiyorsun? Ayrıca, Magento'ya gelen her http isteğinin sonunda yapılandırma ağacını yükleyeceği anlaşılıyor, doğru mu? Boyutunu küçültebilmemin bir yolu var mı? Muhtemelen 10k Magento örneği almayı düşünmeliyim ... ne kadar kaynağa ihtiyaç duyacağına dair herhangi bir düşünce? Çok teşekkür ederim Kevin!
Jack.W

Ama 10k Magento kurulumuna sahip olmak 10k mysql örnekleri demek doğru mu? Bunun nasıl yapılacağı hakkında hiçbir fikrim yok ya da iyi bir fikir ise ..
Jack.W

1
Hayır, bu 10k mysql veritabanlarına sahip olmak anlamına gelir, ancak bunların 10k'si tek bir mysql örneğinde olabilir.
Christian


1
10k Magento kurulumu, 10k MySQL veritabanı anlamına gelir, ancak bu yayılır. Mevcut çekirdek kodun 10k mağazalarla çalışmasını sağlamaktan 10k ayrı Magento kurulumu komut dosyası dağıtmak çok daha kolay olacaktır.
Kevin Schroeder

1

Çekirdeği hacklemeyi ve web sitesi önbellek bölünmelerini etkinleştirmeyi deneyebilirsiniz. Veritabanını hacklemeyi ve yapılandırma bilgilerini belleğe kaydetmeyi deneyebilirsiniz. Yapılandırma önbelleğini daha akıllı bir şeyle değiştirmeyi deneyebilirsiniz - geçersiz kılma verilerini dinamik olarak alırken xml dosyalarındaki [statik ve tüm web siteleri ve mağazalar için geçerli olan] bilgileri önbelleğe almayı diyelim.

Ben bir sunucu adamım, bu yüzden veritabanı ile mucking gitmek istiyorum. Özellikle önemsiz olduğu için.

Veritabanı sunucunuz üzerinde denetiminiz varsa: core_config_data tablosunu core_config_data_offline olarak yeniden adlandırın MEMORY depolama motorunu kullanarak yeni bir core_config_data tablosu oluşturun http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html Core_config_data_offline'daki tüm verileri core_config_data'ya kopyalayın

Tüm verileri oradan core_config_data_offline'a kopyalayıp kopyalamadığını core_config_data olup olmadığını kontrol etmek için bir cron işi ayarlayın. Başlamazsa oluşturun ve core_config_data_offline'dan core_config_data'ya her şeyi kopyalayın

Yapılandırma önbelleğini kapatın. Yapılandırma önbelleği açıkken, yapılandırma verileri veritabanından ilk kez okunduğunda bir performans artışı elde edersiniz - bundan sonra önbellekte ve acı çekersiniz. Aşağı yönde xml dosyaları artık önbelleğe alınmaz, bu nedenle bir dizi xml dosyasını ayrıştırma performansı isabeti için serileştirmeyen devasa yapılandırma verilerinin performans isabetini takas ettiniz.

Ayrıca Mage / Core / Model / Config.php dosyasını değiştirmeyi denemek ve tek tek web sitesi önbelleklerini etkinleştirmek isteyebilirsiniz. Varsayılan olarak, her bir depoya özgü yapılandırma verisi ayrı ayrı önbelleğe alınır. Tüm web sitesi yapılandırma verileri tek bir nesnede önbelleğe alınır.

Bunun yalnızca yapılandırma geçersiz kılmaları için olduğunu unutmayın [yönetici ayarları]. Yani tüm konfigürasyon değişikliklerinizi mağaza düzeyinde yaparsanız, önceden ayarladığınız. "Web sitesinden devral" seçeneğini kullanırsanız ve mağazanızın çoğunu site düzeyinde özel yapılandırma değişiklikleri yaparsanız, önbellek her web sitesini içerir. Bölerek çok daha iyi kırılabilir. korumalı $ _cacheSections = dizi ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'mağazalar' => 1, 'web siteleri' => 0);

için

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
); 

Merhaba Gary, böyle yararlı bir cevap için teşekkür ederim! Bazı sorularım var: 1) Benim gözlem, 1k web siteleri / mağazalar bile, veritabanı sorgu bir sorun değil; öyleyse, bu durumda bellek depolamayı kullanmak yine de yardımcı olur mu? 2) Doğru olup olmadığını bilmiyorum, ancak yapılandırma önbelleği sadece sistem ve modül bilgilerini saklıyor gibi görünüyor; web sitesi / mağaza yapılandırmasıyla bir ilgisi var mı? 3) Magento'nun bir http isteğinden belirli bir mağaza / web sitesi kimliğini tanıması ve böylece yalnızca ilgili yapılandırma dosyasını yüklemesinin bir yolu var mı? Çok teşekkür ederim Gary!
Jack.W

2
Bu öneriler OP'nin belirttiği sorunu ele almaz. Yapılandırma önbelleğinin kapatılması nihayetinde sistemi öldürecektir. Bu, Magento'nun tüm yapılandırma dosyalarını yüklemesine, birleştirmesine, ardından tüm / global öğesinin birleştirilmesine, ardından tüm / web sitelerinin birleştirilmesine ve daha sonra bunların her birinin / depo düğümünde birleştirilmesine neden olur. Bu HER istek için olacaktır. 10k siteleri ile istek başına duvar saati dakika bakarak olabilir .
Kevin Schroeder

Selam Kevin, cevap için teşekkürler; Aslında core_config_data tablosunu belleğe taşımayı, sistem ve modül yapılandırması için önbelleği etkinleştirmeyi, core_config_data'nın yapılandırma ağacında birleştirilmesini durdurmayı ve verilerin bu kısmını okuyan işlevleri doğrudan veritabanından sorgulamayı planlıyorum. Ne düşünüyorsun?
Jack.W

1
Sorun core_config_data değildir. Sorun, mağaza yapılandırmalarının XML'den / global kaynağından birleştirilen / web sitelerinden birleştirilmesidir. Veritabanı çok iyi olur. Yapılandırma birleşmeleri nedeniyle hayattan nefret edecek PHP'dir. Hata ayıklayıcınızda Mage_Core_Model_Resource_Config :: loadToXml adımında 110 satırlarına ve aşağıdaki noktalara özellikle dikkat edin
Kevin Schroeder

1
Şimdi bellek masama geri dönelim. Verileri önbelleğe almak, verileri hızlı bir şekilde erişilebilecek bir yerde saklamak anlamına gelir. Magento, yapılandırma verilerini php serileştirilmiş bir nesneye önbelleğe alır - yapılandırma verileriniz çok büyükse PHP'nin her istek için büyük miktarda veri serisini kaldırması gerektiği anlamına gelir. Xdebug'un nasıl kullanılacağını biliyorsanız, yavaş sayfa yüklemelerinizin bazılarını profille ve unserialize işlevini çalıştırmak için ne kadar zaman harcadığına bakın: php.net/manual/en/function.unserialize.php - eğer büyükse [100 ms'den fazla] "önbellekleme" yapılandırma sisteminizi bozuyor.
Gary Mort
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.