Hangi MySQL Server Magento için daha iyi performans sağlar


30

Magento için MySQL Sunucusu olarak ne kullanıyorsunuz?

  • MySQL (Oracle)
  • Percona
  • diğerleri (MariaDB)

Percona, Magento tarafından yoğun olarak kullanılan InnoDB depolaması için bir dizi iyileştirme sağlar, ancak bu gelişmeler bir Magento mağazasını çalıştırırken fark yaratır.

Performansı nasıl geliştirirsiniz (mimarlıkla ilgili genel yaklaşımlar, innodb_flush_log_at_trx_commit=2vb. Gibi belirli değişkenleri ayarlama hakkında belirli bilgiler yoktur ). NBS'nin master-master replikasyonunu denediğini biliyorum ama bu istikrarlı değil.

Verilerin çoğaltılmasında bazı gecikmeler olduğu için, köle yönelimli okumalarla ana-köle çoğaltması ile ilgili bazı sorunlarla karşılaştım.

MySQL'den olabildiğince uzaklaşmak mı? (Solr ve benzeri arama).


1
FlorinelChis, Soru için teşekkür ederim, ama bu çok geniş bir konudur (performans iyileştirmeleri) ve bir veritabanı motorunun seçimi başlı başına bir alandır. Bu sorunun özellikle Magento ile ilgili güçlü bir bileşeni olmadıkça, bu DBA Sorular ve Cevaplar bölümünde daha iyi sorulabilir . Ancak sorunuzu nerede ortaya koyarsanız, karşılaştığınız belirli sorunlar hakkında daha fazla bilgi vermeniz gerekecektir. Karışıklık için üzgünüm ve iyi şanslar!
Robert Cartaino

Sorunun belirsiz olduğunu ve çok geniş bir konu gibi göründüğünü biliyorum. Magento ile ilgili o kadar geniş değil, çok özel detaylarla ilgili. MySQL, Magento'yu ölçeklendirmeniz gerektiğinde bir tıkanıklık ve deneyimlerime göre, bazı kurulumlarda sadece percona'ya geçiş yapmak performansı artırıyor. Diğer Magento sistem yöneticilerinin ne yaptığını bilmek istiyorum. Daha fazla performans elde etmek için innodb-floş-log-at-trx-commit = 2 olarak ayarlamanız gereken çok özel bir bilgi aramıyordum, ancak Mysql, percona veya başkalarını (MariaDB) kullanma konusundaki bir yaklaşıma doğru.
FlorinelChis

FlorinelChris, bir etki alanı uzmanı değilim, ancak oylamaya ve bayraklara dayanarak, bu sorunun yararlı bir yanıt alabilmesi için daha fazla bilgiye ihtiyaç duyduğunu / garanti ettiğini düşünüyorum. Ancak, topluluğun uygun şekilde halletmesine izin vermek için yeniden açmaktan memnuniyet duyuyorum. Hangi bilgileri ekleyebileceğinizi görmek isteyebilirsiniz, böylece insanlar size en iyi nasıl yardımcı olacaklarını tahmin etmekten vazgeçebilirler.
Robert Cartaino

Yanıtlar:


73

Burada geniş, geniş bir optimizasyon dünyasına giriyorsunuz ve kesinlikle tüm yaklaşımlara uyan bir boyut yok.

Performansı tanımla

Tek bir kullanıcının sayfa yükleme süresini mi, yoksa toplam kapasite / toplam eşzamanlılığı mı demek istiyorsunuz? İkisi birbirinden çok farklı - ve kesinlikle birbiriyle ilgili değil. Sınırlı kapasiteye sahip hızlı bir mağazaya sahip olmak tamamen mümkündür; veya çok fazla kapasiteye sahip yavaş bir mağaza.

Öyleyse, herhangi bir performans türünü ele alırken:

  1. Tek kullanıcı algılanan sayfa yükleme süresi
  2. Toplam kapasite / eşzamanlılık

Her biri kendi çözümleriyle bağımsız olarak ele almalısınız - özellikle de kendi darboğazları olduğundan.

Şimdiden, sunucunuzun diğer yönlerini mağazanız için en iyi şekilde yapılandırmış olan yetkili bir ev sahibi olduğunuzu varsayalım.

Tek kullanıcı algılanan sayfa yükleme süresi

MySQL darboğazı mı
Hayır. Doğrudan değil. Tamamen gecikme ile ilgili, sayfa yükleme zamanını test ederken çoğu durumda - sadece önbelleklere isabet edilir. Yani burada anahtar gecikmeyi en aza indirmektir.

  • MySQL önbellek boyutlarını uygun şekilde ayarlayın (doğru cevap yoktur, ayarları mağaza başına aylık olarak tamamen farklı şekilde ayarlarız)
  • Ağ gecikmesini azaltın. 64 baytlık kareler için; 10Mbps için 51.2µs, 100Mbps için 5.12µs ve 1Gbps için 4.096µs. Bu sadece 100Mbps'den 1Gbps'ye geçerek% 20'lik bir iyileşme sağlar. s1
  • Ağ kapasitesini arttırın. Bir Web ve DB sunucusu arasında, genellikle 10 MB / sn'den fazla bir değiş tokuş yapıldığında, saniyede birçok megabaytlıkta şaşıracaksınız - s1 için minimum 100Mb / s gereklidir . Veya sadece DB sunucusunu yerel olarak taşıyın.
  • SOLR’ı kullanma. Dış motorlar bazen daha uygundur, SOLR kesinlikle LARGER katalogları için daha hızlıdır (ve daha büyük kataloglara vurgu yapıyorum ). Ayarlanmamış SOLR bile katmanlı gezinme ve arama sonuçlarını MySQL'den daha hızlı üretecektir.

Ancak bu değişikliklerin sayfa yükleme süresi üzerinde kısmi bir etkisi olacak - darboğazın başka bir yerde olduğu yerde.

  • Uygulamayı ayarlayın. Magento, koleksiyon oluşturma ve önbellekleme gibi oldukça büyük hatalara sahip; performansı düşürebilen çok sayıda büyük temel kod sorunuyla karşılaştık. Birkaç durumda, katmanlı gezinme üzerindeki ürün sayısı göstergesinin kaldırılması, 2 saniyelik büyük bir koleksiyon yüklenmesine neden oldu.
  • MySQL yavaş günlüklerini inceleyin. Yavaş sorguları kontrol edin ve gerekirse dizinler ekleyin. Karmaşık bir sorguyu, uygun dizinlere sahip olan ve olmayan birden çok birleştirme ile çalıştırma arasındaki fark, on saniye olabilir .

Uygulama darboğaz olduğunu. Yazılım değil. Bu nedenle, yalnızca temel kodun iyileştirilmesi veya şablonunuzun daha az ağır hale getirilmesi, performans üzerinde ANY MySQL yapılandırma değişikliğinden çok daha büyük bir etki yaratacaktır .

Neyle uğraşmazdık

  • Depolama motorunu değiştirme. MariaDB ve Percona aynı InnoDB motorunu paylaşıyor - Percona XtraDB. Bir ve aynı olarak kabul edilebilirler. Tekli sorgu yürütme süresi açısından - performans tam olarak bir vanilya MySQL derlemesini yansıtır. Bu yük / eşzamanlılık altında devreye girer.
  • Bir MySQL kölesini çalıştırmak. Bu, köle fiziksel olarak daha yakın bir yerde bulunmadıkça (ağ açısından) veya kölenin ana sistemden daha iyi donanıma sahip olmadığı durumlarda performansı geliştirmez. Bu yük / eşzamanlılık altında devreye girer.
  • Harici bir DB sunucusunu çalıştırma. Bu, pek çok ev sahibi / ajans tarafından defalarca dağıtıldığını gördüğümüz en kötü tavsiyedir. Donanım / kaynaklar üzerinde bir tavana ulaşana veya birden fazla web sunucunuz varsa (okuma: yüksek kullanılabilirlik), bir Magento mağazası için yerel makinedeki MySQL iyi bir fikirdir. Tüm ağ yükünü ve gecikmeyi keser. Hatta bir 100GB / s ağ (evet, saniyede yüz gigabit) olmaz , çiğ hacmi için yerel bir unix soket ile karşılaştırmak üretilen iş ve gecikme.

s1 Sadece ayrı veritabanı sunucuları için. Yerel DB sunucuları için geçerli değildir.

Toplam kapasite / eşzamanlılık


Belki MySQL darboğazıdır . Ancak PHP performansınızı ve kapasitenizi bir kez MySQL'in işleri yavaşlattığı noktaya çiviledikten sonra. Varnish ve FPC'yi uygun şekilde yapılandırdıysanız (ikimizinde de kaç tane başarısız girişimde bulunduğumuzu bize başlatmayın) - o zaman MySQL bir darboğaz haline gelir.

Yani yukarıdaki değişikliklere ek olarak.

  • MySQL motorunu değiştirin. XtraDB, yük altında üstün performans gösterebilir ve hisse senedi MySQL dağıtımına göre gerçek faydalar gösterir.
  • MySQL ile güncel kalın. 5.5 yük altında 5.0'dan daha iyi performans gösterir.
  • PHP MySQL sürücüsünü değiştirin. PHP 5.3 ve daha yenisinin yerel bir MySQL sürücüsü var, ancak bazı durumlarda, Magento için MySQLND'den daha iyi performans sağlamak için ayrı bir sürücü ile PHP 5.2'yi bulduk. Kendin için test et
  • Arama motorunu değiştir. Aramayı SOLR / Sfenks'e (veya hatta bazı üçüncü taraf harici servislere) taşımak, işlem yapmayan yükün yükünü gerçekten hafifletebilir (yani, insanlar sipariş vermeyen)
  • Katmanlı navigasyon motorunu değiştirin. Yine, SOLR katmanlı navigasyon için mükemmel bir motordur ve kilitlenmemesi nedeniyle MySQL'den çok daha hızlıdır.
  • Bir MySQL slave ekleyin. Bu , göz atma (işlemsel olmayan) yükleme işlemine yardımcı olur, ancak saatte daha fazla sipariş işlemenize yardımcı olmaz - bu verileri işlemek ve çoğaltmak için Master'a bağımlı olduğundan

Neyle uğraşmazdık

  • Usta / Usta. Master / Slave kurulumunun donanım satürasyonunun oldukça yüksek devrilme noktası nedeniyle (saatte 1000 siparişin üzerinde) - Master / Master'ı üretimde kullanmak için hiçbir zaman bir gereksinim bulamadık. Kapsamlı testler yaptık, ancak performans perspektifinden ve Master / Master'ın içsel riskleri ve problemleriyle avantajlı olduğunu asla bulamadık, buna değmez.

Oku ve Yazma Ölçeklenebilirliği

Son paragraf gerçekten önemli bir okuma ve yazma ölçeklenebilirliğine yol açar. Okuma ölçeklendirme, gittikçe daha fazla köle ilavesiyle çok fazla karmaşıklık olmadan oldukça sınırsız bir şekilde gerçekleştirilebilir.

Magento’nun Okuma Yazma’nın oranı göz önüne alındığında% 0.1’dir. Yazmaların bir sorun oluşturmaması gerekir. Bu yüzden MySQL Cluster ve otomatik sharing gibi akıllı özelliklerinden bahsetmedim (tabloları ayrı makinelere bölmek).

Donanım, donanım, donanım

Donanım, gelişme söz konusu olduğunda kolayca en hızlı cevaptır, bu yüzden her iki senaryoda da kasıtlı olarak yukarıda bahsetmedim.

Ancak, dünyadaki tüm yazılım değişiklikleri, temel donanımınızın yetersiz olması durumunda herhangi bir fark yaratmayacak. Bu demek olabilir ...

  • Sınırlandırılmış arabellekli düşük kaliteli anahtarlar
  • Aşırı doymuş ağ bağlantıları
  • Coğrafi olarak uzak sunucular
  • Kötü ağ QoS / CoS
  • Sınırlı toplam RAM miktarı
  • Düşük bellek bant genişliği RAM
  • Düşük GİB HDD alt sistemi
  • Yazılım RAID denetleyicisi
  • Düşük saat hızlı CPU
  • Düşük bant genişliği yonga seti
  • Donanım sanallaştırma (hemen hemen Çekirdek Düzey Sanallaştırması dışındaki tüm türler)

Günümüzde, donanıma göre ne kadar yükseğe çıkacağınıza dair gerçekten yüksek bir tavan var. Bulut donanımı oldukça vasat olma eğiliminde olduğundan, "bulutta" sonsuz ölçeklendirme efsanesini görmezden gelelim. Örneğin, Amazon'un amiral gemisi modelleri yalnızca 12 Çekirdek @ 3.3 GHz'tir. Ancak bunun dışında, bazı çok güçlü sunucular mevcut - en iyi sunucumuzda 160 çekirdek ve 2TB (evet, Terabayt) RAM var. Henüz kimsenin yeteneklerini aştığını görmedik.

Dolayısıyla, dikey ölçeklendirme için muazzam bir kapsamınız var, hatta yatay ölçeklendirmeyi düşünmeniz gerekmeden önce.

Sürekli hareket eden hedef

Performansın peşinde olan darboğazın sürekli hareket etmeye devam edeceğini söylemeye değer.

Bir hisse senedi Magento mağazası için.

Önbellekleri aç. PHP tıkanıklığı olan
bir arka uç önbelleği ekleyin. PHP darboğazı
olan Uygulama düzeyinde bir tam sayfa önbellek ekleyin. PHP, darboğazdır
Sunucu düzeyinde bir ön uç önbelleği ekleyin (örn. Varnish). MySQL, darboğazdır
Alternatif bir arama / katmanlı navigasyon motoru ekleyin (örn. SOLR / Sfenks). PHP darboğaz olduğunu
Daha fazla uygulama sunucusu ekle. MySQL darboğazıdır
MySQL kölesi ekle. Ön uç önbellek tıkanıklığıdır
Daha fazla ön uç önbellek sunucusu ekleyin. PHP darboğaz olduğunu
Daha fazla uygulama sunucusu ekle. SOLR / Sphinx darboğaz

Et cetera.

Bu hemen hemen durulama-yıkama tekrarı haline gelir. Ancak anlaşılması gereken şey, MySQL'in kesinlikle optimizasyon için ilk çağrı limiti olmadığı - ve gerçekten sadece MySQL'in PHP ile orantılı olarak daha fazla CPU harcadığı zaman ortaya çıkıyor - ve bu SADECE FPC ve Vernik kullanımdayken gerçekleşiyor. ve sunucu (lar) tamamen siparişleri ve başka hiçbir şeyi işlemiyor (çünkü her şey önbellekte bulunuyor).

Kör değişiklikler yapmayın

Basitçe bir MySQL kölesi eklemek, çünkü bize yardımcı olacağını söylediğimizi okuduğunuzda, performansınıza ve güvenilirliğinize büyük bir maliyet getirebilir. Sıkışık bir ağ, düşük özellikli bağımlı sunucu veya uygun olmayan ayarlar, mağazanızın başladığından daha yavaş olmasına neden olabilecek çoğaltma sorunlarına neden olabilir - veya Ana ve Bağımlı arasında senkronizasyon sorunlarına neden olabilir.

Bazı şeyleri perspektife koymak - bazı gerçek dünya örnekleri.

Örnek 1 - Saat başına 300 sipariş

Saatte 300 sipariş vermek için aşağıdaki donanımı kullandık ; ve sadece bu devrilme noktasında - daha sonra özel bir MySQL sunucusu ve yerel bir MySQL kölesi ekleme ihtiyacını hissettik.

1 Sunucu
İşlemci: 2x Intel E5-4620
RAM: 64 GB HDD: 4x80k IOP / s SSD'ler
RAID: Donanım RAID 10
Magento Versiyon: Magento EE
OS: MageStack

Tüm zaman boyunca, yük ortalamaları 3.00'un altında kaldı.

Örnek 2 - Saat başına 180 sipariş

Sadece iki gün önce, yeni bir müşterimiz kolayca büyük bir trafik artışı yaşadı. Tek bir sunucu ve Magento Topluluk Sürümü ile saatte 180 sipariş işleme .

1 Sunucu
İşlemci: 2x Intel E5-4620
RAM: 64 GB HDD: 4x80k IOP / s SSD'ler
RAID: Donanım RAID 10
Magento Versiyon: Magento CE
İşletim Sistemi: MageStack
Web Sitesi: Wellgosh.com

Tüm zaman boyunca, yük ortalamaları 6.00'un altında kaldı. Bu senaryoda yük daha yüksekti ve bu birkaç faktöre bağlıydı.

  1. Örnek 1'deki gibi hiçbir mağaza tarafı ayarı gerçekleştirilmedi
  2. Uygulama düzeyinde bir FPC eksikliği

Bunun nezaketini verdiğimizde, yine de grafikler aracılığıyla geri bildirimde bulunacak ayrıntılı istatistiklere sahibiz. Bunlar, ayrı bir Magento mimarisinin ana bileşenleri (yük dengeleyici, web sunucusu, db sunucusu vb. - MageStack kullanarak ) arasında nasıl dağıldığının mükemmel bir hikayesini anlatıyor .

Yani önden arkaya ... bakmak istediğiniz tarih 22 Şubat'ta saat 12: 00'de.

Güvenlik Duvarı Paketleri
Güvenlik Duvarı Paketleri

Vernik Trafiği
Vernik Trafiği

Nginx Trafik
Nginx Trafik

MySQL Yükü
MySQL Konuları MySQL Bayt MySQL Sorguları

CPU Yükü
CPU Yükü

Ve en önemlisi, yük dağılımı

Bu görüntü gerçekten her şeyi anlatıyor. Ve bu MySQL'in kesinlikle bir yük değil - en azından henüz. Bu yüzden tavsiyemiz, saatte birkaç binden fazla emri işlemediğiniz sürece performans endişelerinizi başka bir yere odaklayın.

Yük dağılımı

Ve özet olarak

Performans değişikliği yapmak "herkese uyan tek beden" değildir. Mevcut tıkanıklıklarınızı analiz etmek ve mağazanıza ve altyapınıza uyacak şekilde ince değişiklikler / düzeltmeler yapmak bir durumdur.

Ancak performans bir yana, Percona'yı kullanmanın başka yararları da var.

Neredeyse sadece Percona XtraDB kullanıyoruz. Magento için özel olarak geliştirdiğimiz ve işlem sırasında Percona'ya danıştığımız özel derlenmiş MySQL sürümlerini çalıştırıyoruz. Ancak bu seçimi etkileyen sadece performans değildi.

  • Percona Araç Takımı
    • pt-sorgu sindirimi
    • xtrabackup
    • vb.
  • Percona serbest bırakma frekansı
  • Percona danışmanlık desteği
  • InnoDB havuz koruması ile sıcak önbellek yeniden başlatılıyor

Ve daha fazlası. Bu yüzden MySQL üzerinden kullanmanın sadece performanstan başka avantajları vardı. Aslında - MySQL, performans ve istikrar arayışı konusundaki endişelerimizin en küçüğüdür ve daima olmuştur.

Atıflar : wellgosh.com , sonassi.com , iebmedia.com .


Bu uzun bir cevap :) Çok takdir, teşekkür ederim. Ölçek ve MySQL üzerindeki yük ile ilgili olarak MySQL'den munin şemasıdır: twitter.com/ze_m0n5t3r/status/232864932482396160 . Magento’yu optimize etmek sürekli bir işlemdir (çeşitli hatalar, optimize edilmemiş kod, vb.). Yükü azaltmak (arama / nav'ı solr'a taşımak, daha iyi önbellekleme) ilk yaklaşımdır. Ancak aynı zamanda, DB'nin soğuk bir önbellekle daha iyi davranması gerekir. Ve bu olduğunda daha büyük kapasiteye sahip daha yavaş bir web sitesi arıyorum.
FlorinelChis

Rica ederim. Müşterilerimizin yaptığı gibi hızlı bir web sitesine ve yüksek kapasiteye sahip olamayacağınızı söylemek için hiçbir neden yok . Belli ki MySQL performansında yukarıda bahsettiğimden biraz daha fazlası var. Ancak bu, 'gizli sosumuzu' bir şekilde dağıtıyor olacaktı. Bu cevabı küçük mağaza sahiplerine (<25k uniques / day) MySQL için 'başlangıç' rehberi olarak verdim.
Ben Lessani - Sonassi,

Sadece bir taslak olarak. Grafiğinize bakıldığında, uçlarınız normal yükünüzün yaklaşık 10 katına ulaştı, güncellemeler düşük kaldı ve seçimler en büyük yükü gösterdi. Müşteri girişleri, arama uygunluğu / sorgular veya tanrı yasaklayan oturumlar olan bir kumar oynardım. Ancak yine de bir sorun teşkil etmeyecek kadar küçük bir sayı veya Üstat / Üstat olarak bile düşünülmeli. Bu nedenle grafiğinize göre, daha fazla donanımın basit şekilde eklenmesi yeterli olmuyor; Bundan sonra bir köle (ler) ile. Ve önbelleğinizi yeniden başlatmalar arasında sıcak tutmak Percona, s.onas.si/5g8s
Ben Lessani - Sonassi ile

arama solr, oturumlardı - memcache. Başarılı bir usta çalışan birini tanıyor musunuz? (NBS bu konuda başarısız oldu, bununla da başarısız olduk, Magento ile dengesiz, diğer hafif php uygulamalarında iyi çalışıyor)
FlorinelChis

1
Bu inanılmaz bir cevap. Sadece bunu söylemek istedim.
dustbuster
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.