Şu anda web sunucusundan ilk yanıtın İngiltere'de 200 msn altında gelmesi şartı ile çalışıyoruz. Şu anda yük dengeleyici altında 2 özel web sunucusu ve 1 db sunucu altında, 800ms geliyor.

Şu anda sitede 5'ten az müşteri, 2 ürün, 4 kategori var, şu anda sitenin ön yüzü yok, stilsiz ve görselsiz.

Ayrıca Varnish ile nginx'te çalıştırılıyor.

Birisi bana web sunucusu kurulumları hakkında herhangi bir tavsiyede bulunabilir mi? Bizimki neden yavaş geliyor? Bunu optimize etmek için neler önerebilirsiniz? % 400 daha hızlı olmanız gerekiyor!

Isıracağım.

Bu web sunucusundan ilk yanıtın İngiltere'de 200ms'in altında gelmesi gerekiyor
. Şu anda sitenin ön yüzü yok, stilsiz ve görselsiz.

Varnish ya da FPC'nin (ya da her ikisinin) yardımı olmadan bu rakamları elde edemezsiniz. Umarim ki bu rakam da statik içerik (eklemek istediğinize karar verdiğinizde) - elde etmek neredeyse imkansız (resim / js / css az olması yetersizdir) içermesi gerekmez.

800ms'de geliyoruz
Ayrıca Nginx'te Varnish ile çalıştırılıyor.

Varnish yanlış yapılandırılmış.

Düzgün bir şekilde yapılandırılmış Varnish kurulumu <100ms sayfa yükleme süresi sağlar (<10ms'ye yakın görüyoruz).

Aslında, Magento için böyle bir şey görmeyi beklemelisin.

Bir müşteri giriş yapmadığında ...
Yani. Benzersiz bir oturum oluşturmadı (sepete ekle / dilek listesi, oturum açma vb.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Bir müşteri giriş yaptığında ...
Yani. Benzersiz bir oturum oluşturduktan sonra (giriş yapmış, alışveriş sepetindeki öğeler vb.). Bu noktada Varnish muhtemelen kapalı olacak. Ve eğer ESI'leri kullanmayı seçtiyseniz - ters çağrılara bağlı olarak, FPC önbelleği ile aynı sayfa yükleme süresini koruyabilir (önyükleme ek yükleri nedeniyle) - veya sayfa önbelleklemenin ötesinde sayfa yükleme süresini artırabilir.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

Varnish'i ayarlama durumu değil - bu bir durumdur - "aslında hiçbir şey önbelleğe almıyorsunuz" .

İdeal Magento sunucusu yapılandırma dosyaları

Bir tane yok, peki, tam değil.

Tamamı Magento mağazalarında - değişen boyutlarda ve kapasitelerde 400'ün üzerinde sunucu kullanıyoruz. Ve bir tanesine sahip olduğumuz yapılandırma dosyalarının bir başkasınınkiyle aynı olması nadirdir. Çünkü tüm işletmeler aynı değildir.

Darboğazlar birçok farklı nedenden ötürü oluşabilir:

1. Aktif oturumlarla birlikte çok sayıda ziyaretçi eşzamanlılığı
2. 'Kötü' tarama botlarının kurbanları, gerekli, paha biçilmez yük üretiyor
3. Katmanlı navigasyon isabetlerinin yüksek oranı
4. Çok sayıda arama sorgusu
5. Saat başına yüksek işlem hacmi
6. Zayıf yapılı şablon
7. Çok fazla / yavaş / hantal 3. parti uzantıları
8. 404 hit oranının yüksek olmasına neden olan eski gelen bağlantılar
9. Ağ arayüz kapasitesi sınırlıdır
10. Büyük / karmaşık katalog (birçok ürün / kategori / özellik)

Böylece tüm bu spektrumdaki mağazalarda, her birinin daha optimum performans için farklı bir yaklaşımı var.

Yukarıda belirtilen sorunları çözmek için; kasıtlı olarak sadece "daha fazla / daha iyi donanım" belirtmekten kaçınacağız

1. Vernik'in ötesinde bir FPC kullanın
2. Ağ kenarındaki bozuk botları filtreleyin / engelleyin - veya çerez durum / URL ne olursa olsun tüm isteklerinizi Vernik'e yönlendirin
3. Stok katmanlı gezinmeyi SOLR olarak değiştirin, katmanlı gezinme filtrelerini bağımlı hale getirin
4. Stok aramasını SOLR olarak değiştir
5. MySQL yükünü Master / Slave yapılandırmasına dağıtın - yalnızca tarama yükünün Varnish / FPC tarafından emildiğini garanti ettiğinizde yapın
6. Şablonu yeniden oluştur
7. Onları çıkar
8. Erişim günlüklerini sürekli izleyin ve teslimattan önce Nginx / Varnish'te URL'leri yeniden yazın. Nginx düzeyinde yapıyorsanız - Vernik'in 301/302 yönlendirmelerini önbelleğe aldığından emin olun.
9. Statik içeriği bir CDN'ye bölme veya bağlantıyı iyileştirme
10. Daha fazla donanım ekleyin (bir noktada söylemek zorunda kaldık)

Yani bu akılda tutulacak - muhtemelen aynı olacak olan bir Nginx yapılandırma dosyası, PHP fcgi havuzu yapılandırma dosyası, MySQL yapılandırma dosyası veya Vernik yapılandırma dosyası olmayacağını göreceksiniz. Donanımla kendisini değiştiren çift; kullanılabilir bellek, G / Ç performansı (HDD ve Ağ) ve CPU - ve istediğiniz 400% performans kazancına neden olan ince varyasyonlar olduğunu göreceksiniz - ancak çevrimiçi olarak kolayca bulamayacağınız hızlı bir cevap yok.

Peer 1 sponsorluğundaki Peer 1 sponsorlu Magento tanıtım kağıdını kopyalayıp yapıştırabilirsiniz (tavsiye etmiyoruz); ayarların kullanılabilir hafızanızı, iş parçacığı sınırlarınızı, TCP / IP durumlarını, G / Ç kapasitesini aşmadığını ve vanilya Apache / mod_php yapılandırmasından daha düşük performans göstereceğini umuyoruz.

Öyleyse devam edelim.

İdeal Magento sunucu yığını

Bu sizi gerçeğe yaklaştırmak için daha olasıdır. Bunu göstermek için iyi bir örnek, özel bir Magento OS'nin nasıl yapılandırıldığını göstermektir, MageStack

Ayrı alt bileşenleri alın ve Magento mağazasını çalıştırmak için uygun şekilde yapılandırıldığında en uygun / kritik yazılımların bir listesini elde edin . Özellikle:

Güvenlik Duvarı, DOS filtresi, Yük Dengeleyici, Vernik, Nginx, PHP, Redis, Memcached, MySQL

Peki sorduğun zaman:

En İyi Magento Sunucu Kurulumu nedir?

Hedefin tam olarak nedir?

1. Yüksek kullanılabilirlik
2. Güvenilirlik
3. İdarenin basitliği
4. Verim
5. Ölçeklenebilirlik

Yeterince ders anlatıyor, nasıl yaparız?

Sunucu arızasında verilen cevabı kısmen benzer bir damarı yansıtmak için . Hizmetinizde olan 3 sunucunuz var - bu yüzden ilk önce onları mümkün olan en iyi şekilde yönlendirin. Bu cevabın kapsamı çok ötesinde olduğu için yüksek düzeyde kullanılabilir bir çözümden kaçınacağız.

Çok sunucu yapılandırması için gerekli alt bileşenler şunlardır:

• Firewall
• Yük dengeleyici
• Web sunucusu
• MySQL Sunucusu
• Ortak depolama

Bu yüzden bazı sistemlerde çok amaçlı olacağız. PCI-DSS uyumluluğu, her sunucu için bir rol belirler. Böylece 5 rol ve 3 sunucu ile derhal ihlal edilirsiniz. MageStack bunu sanallaştırma kullanarak halleder - siz de aynısını yapabilirsiniz.

Sunucu 1: Yük Dengeleyici + Web sunucusu
Sunucu 2: Web sunucusu
Sunucu 3: Veritabanı sunucusu

Düşük gecikmeli ve anlamlı ağ bant genişliği (> 1 Gbps, <125μs) olmadan, ortak depolama sahip ziyade - sen sadece her makinede mağaza kök dizini depolamak ve verileri çoğaltmak, ya gerçek zamanlı olarak kullanmanın için onun daha iyi ionotifykullanarak veya süresi doldu bir croniş. Yine, NFS gibi ağ dosya sistemlerinden veya Gluster veya DRBD gibi çoğaltılmış blok cihazlardan kaçınacağız - engin ayar ve uygun ağ bant genişliği gerekli.

Vernik, mümkün olduğu kadar cepheye yakın oturmalıdır. Ancak Vernik, SSL şifresini çözemez. Yani bir SSL sonlandırıcı ile birleştirin; Nginx, Pound, Stunnel, Stud vs. Varnish'te yerleşik yük dengeleyici mükemmel değil - ancak 2 sunucu kurulumu için yeterli olacaktır.

Nginx + PHP-FPM iyidir, ancak Nginx kool yardımının çok içmeyin. Geleneksel bir Apache / mod_php konfigürasyonunda neredeyse aynı şekilde çalışacaktır, Nginx'i neden kullanmama konusunda iyi bir okuma . Nginx iyidir, çok iyi bir infact, ancak kesinlikle bir Magento mağazasının darboğazı değil - ve karmaşıklığı ve yerli Magento desteğinin olmaması. Acemi sistem yöneticilerinin çoğu Apache / mod_php kullanmaktan başka bir şey yapmaz. Bu, PHP-FPM kullanımına ilişkin eski bir öneri gibi görünebilir - ancak performans testlerimiz Nginx çözümüyle performansın sadece ~% 7 daha hızlı olduğunu göstermiştir - uygun şekilde yapılandırıldığında. Yüksek performanslı, güvenilir bir Nginx / PHP-FPM kurulumu için gerekli ayarlama ve deneyim, Apache / mod_php'den daha iyi performans göstermesi için oldukça geniştir. Hangisini kullanmayı seçerseniz seçin.

Veri tabanı sunucusu basittir, MySQL. Ancak daha önce de belirtildiği gibi, yüksek dönüşüm oranlı bir siteniz varsa, Master / Slave yapılandırması önerilir. Bu yaklaşımı takip edip etmemeniz bu makaleyi okuyarak belirlenebilir .

Sonra periferik arka uç önbellekleriniz Memcached ve Redis. Küçük mağazalarda, oturumları bir Memcache örneğinde ve hızlı arka uç önbelleğini başka bir yerde depolamak iyi performans avantajları sağlar. Önbellek etiketlerini yavaş arka uçta saklamayı savunmuyoruz - çünkü verdiğinden daha fazla soruna neden oluyor. Bu nedenle Memcached kurulumunda önbellek etiketlemekten vazgeçmeniz gerekir . Bunun yerine, böyle bir yapılandırmayı kullanmak bu .

Redis, Magento'ya özgü değildir, ancak Memcache'den daha iyi bir çözüm olan Colin Mollenhour'un uzantısı ile, önbellek etiketlerini, oturum depolamayı ve hatta kalıcı önbellek depolamasını destekler - Memcache kadar uçucu değildir . Ancak sakıncaları var. Biz üzerinde bulduk büyük ölçekli , LRU mekanizması biraz başarısız üretim mağazalarında (> 500 siparişler / saat,> 30 k benzersizler / saat) doygunluk noktası vuruldu kez önbellek (ve etiketleri) çok hızlı bir şekilde doldurmak ve ki ( farklı ortamlara rağmen) ve büyük bir acil tıkanıklığa neden olur. Bu yüzden düzenli olarak eski kayıtları manuel olarak budamak akıllıca olur.

Peki hangi donanım ne için kullanılmalı?

Web sunucuları: En hızlı CPU, en fazla CPU çekirdeği, 2GB RAM / Çekirdek
DB sunucusu oranı : Hızlı CPU, en hızlı disk G / Ç, en çok RAM

Bu nedenle, 3 makinenizi çoklu kullanımda, en iyi düzen şöyle olacaktır:

Sunucu 1: SSL Terminator -> Vernik -> Nginx / Apache> PHP
Sunucu 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Sunucu 3: MySQL

Her uygulamanın özel yapılandırmasına gelince. Bu, sizin donanımınızın özelliklerine, mağaza karmaşıklığınıza, ziyaretçinin türüne ve doğasına ve ziyaretçilerin gerçek hacmine bağlıdır.

Bu küme yapılandırmasıyla harika bir yoldasın. Redis için özel bir önbellek ana bilgisayarı eklemenizi öneririm; CPU gücü ve çokça RAM (~ 64 GB) olan birini seçin.

İşte yüksek oranda kullanılabilir, hataya dayanıklı, dağıtılmış ve yük dengeli bir LEMP kümesi için kullandığım yapılandırmaların tam listesi . MySQL, php-fpm, nginx ve Redis app/etc/local.xmliçin core_config_datatablo ve yapılandırmaları içerir . Hepsi Ubuntu 12.04 LTS 64-bit çalıştırın. Yapılandırmalar, dezavantaj olmadan birçok optimizasyon içerir.

Önemli

• Yönetici kullanıcılar: 46
• Kategoriler: 2.450 (en büyüğü 2.400 ürüne sahip)
• Ürün birimleri: 101.000
• Combo ürünler: 484
• Ürün ilişkileri: 54.000
• Stokta ve etkin yapılandırılabilir ürünler: 10.100
• İYS blokları: 3,100
• CMS sayfaları: 1.400

Ağustos 2013 trafiği:

• Aylık 40 milyon sayfa görüntüleme
• 2,3 milyon benzersiz ziyaretçi
• 46.000 aylık ödeme
• ABD’den gelen ziyaretçilerin% 89’u

Web barındıran

Yedekli, yüksek oranda kullanılabilir donanım güvenlik duvarları ve donanım yük dengeleyici arkasında 10 ana bilgisayar vardır. Çoğu statik varlık bir CDN'ye boşaltılır.

• site genelindeki ortalama yanıt süresi: 282 ms
• Ortalama FPC yanıtı: 48 ms
• yük ortalaması: 0.6 ile 1.0 arası (testlerde, ortalama performans ~ 5.0 olduğunda,% 35 düşer.)
• Çift Intel Xeon İşlemci E3-1230 V2 @ 3.30GHz (her biri 4 çekirdekli)
• 32 GB DDR3 1333 MHz RAM

Modüller

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = modeller
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = üretim
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Önbellek ana bilgisayarları

Otomatik yük devretme özelliğine sahip bir master-slave konfigürasyonunda Redis çalıştıran iki ana bilgisayar vardır. Üç Redis örneği (oturumlar, arka uç ve FPC), verimi artırmak ve kalıcılık davranışlarının ince ayarını sağlamak için kullanılır.

• Saniyede 3.000 komut
• 0,7 ms ortalama yanıt süresi
• 1.0 ile 1.5 arasında ortalama yük
• Quad Intel Xeon CPU E5-2620 0 @ 2.00GHz (her biri 6 çekirdekli)
• 128 GB tamponlanmış DDR3 1333 MHz RAM
• Mekanik diskler, RAID 1, donanım denetleyicisi

Veritabanı ana bilgisayarları

Sıcak yük devretme özelliğine sahip bir ana sistem yapılandırmasında MySQL 5.6.11 çalıştıran iki ana bilgisayar vardır.

• Saniyede 1500 komut
• 1,1 ms ortalama yanıt süresi
• 0,1 (master) ve 0,4 (slave) ortalama yük
• Quad Intel Xeon İşlemci E7- 2860 @ 2,27 GHz (her biri 10 çekirdek)
• 128 GB tamponlanmış DDR3 1333 MHz RAM
• SSD, RAID 1 + 0, donanım denetleyicisi
• MySQL 5.6.11, tcmalloc ile birlikte

Magento için başka bir sunucu ipucu olması gerekir, OPcache ile PHP 5.4 veya 5.5 kuruyor . PHP 5.4 5.3'ten çok daha hızlıdır ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Vernikle önbelleğe alınmadığında ve varsayılan olarak etkin olmadığında magento sayfa hızını iyileştiren önemli bir ipucu daha eklemek istiyorum (sepet sayfası yükleme süresi 6sc'den 1.5sc'ye değiştirildi).

/Etc/mysql/my.conf içinde mysql sorgu önbelleğini etkinleştir

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type bunu etkinleştirirse, önbellek boyutu bellekteki önbellek tarafından kullanılan değerdir ve önbellek sınırı, önbellek için sorgu sonucunun maksimum boyutudur

Mevcut konfigürasyonumuzla ilk yanıtı 400 msn'de alıyoruz ve belge 2 saniye içinde tamamlanıyor (standart 5mbps bağlantı kullanıyor). Ana sayfamızın boyutu 1 MB'dir.

Kurulumumuz aşağıdaki gibi AWS'ye dayanmaktadır: Bir RDS veritabanına (yük devretme ile) bağlı bir yük dengeleyicili bir ec2 örneğine sahibiz. Hem önbellek depolama hem de oturum depolama için redis önbellek arkaplanlı tam sayfa önbellek de uyguladık.

Günde ortalama 300 - 400 ziyaretçimiz var, ancak redis önbelleğe alma özelliği etkinken, hızı korurken ve maliyetleri düşürürken minimum ek2 kaynak kullanımına sahip olduk.

Yük dengeleyicisine sahip olmamızın nedeni, mevcut kurulumun idare edemediği trafikte ani yükselme ihtimalimiz varsa, ec2'nin otomatik olarak yeni bir örneği önyükleme kurulumunun olmasıdır.