Saya akan gigit.
Respons pertama dari server web harus berada di bawah 200 ms di Inggris.
Tidak ada frontend ke situs saat ini, itu adalah gaya bebas dan gambar bebas.
Anda tidak akan mencapai angka-angka itu tanpa bantuan Varnish atau FPC (atau keduanya). Saya tentu berharap angka itu juga tidak harus menyertakan konten statis (setiap kali Anda memutuskan untuk menambahkannya) - karena hampir mustahil untuk dicapai (singkat memiliki sedikit atau tidak ada gambar / js / css).
Kami datang pada 800ms.
Ini juga dijalankan pada Nginx dengan Varnish
Anda mengonfigurasi Varnish salah.
Instalasi Varnish yang dikonfigurasikan dengan benar akan memberikan waktu pemuatan halaman <100ms (kita lihat lebih dekat dengan <10ms).
Bahkan, untuk Magento, Anda harus berharap untuk melihat sesuatu seperti ini,
Ketika seorang pelanggan tidak masuk ...
Yaitu. Tidak membuat sesi unik (add-to-cart / wishlist, login, dll.)
--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
Uncached Mage default cache Partial FPC cache Total FPC cache Varnish
Ketika seorang pelanggan masuk ...
Yaitu. Setelah membuat sesi unik (masuk, item dalam kereta, dll.). Pada titik ini Varnish kemungkinan besar akan mati. Dan jika Anda memilih untuk menggunakan ESI - tergantung pada panggilan balik, ini dapat mempertahankan waktu pemuatan halaman yang serupa dengan cache FPC (karena overhead bootstrap) - atau benar-benar meningkatkan waktu pemuatan halaman di luar ketidakterbatasan.
--1.4s--------0.8s-----------------0.6s--------------
Uncached Mage default cache Total FPC cache
Ini bukan kasus tuning Varnish - ini kasus - "Anda tidak benar-benar caching sama sekali" .
File konfigurasi server Magento yang ideal
Tidak ada satu, well, tidak cukup.
Kami mengoperasikan lebih dari 400 server, semuanya murni toko Magento - dengan berbagai ukuran dan kapasitas. Dan jarang file konfigurasi yang kita miliki di satu - akan cocok dengan yang lain. Itu karena tidak semua bisnis sama.
Kemacetan dapat terbentuk karena berbagai alasan:
- Banyaknya konkurensi pengunjung, dengan sesi aktif
- Korban bot perayapan 'buruk', menghasilkan muatan yang diperlukan dan tidak berharga
- Proporsi tinggi dari klik navigasi berlapis
- Jumlah kueri penelusuran yang tinggi
- Volume transaksi yang tinggi per jam
- Templat yang dibangun dengan buruk
- Terlalu banyak / lambat / ekstensi pihak ke-3 yang besar
- Tautan masuk yang kedaluwarsa mengarah ke proporsi tinggi dari 404 hit
- Kapasitas antarmuka jaringan pada batas
- Katalog besar / kompleks (banyak produk / kategori / atribut)
Jadi dengan toko-toko di seluruh spektrum ini, masing-masing memiliki pendekatan yang berbeda untuk kinerja yang lebih optimal.
Untuk memecahkan masalah yang diuraikan di atas; kami akan dengan sengaja menghindari hanya menyatakan "perangkat keras yang lebih baik"
- Gunakan FPC di luar Varnish
- Memfilter / memblokir bot buruk di tepi jaringan - atau mengalihkan semua permintaan ke Varnish terlepas dari keadaan cookie / URL
- Ubah navigasi persediaan berlapis menjadi SOLR, buat filter navigasi berlapis bergantung
- Ubah pencarian stok ke SOLR
- Mendistribusikan beban MySQL di konfigurasi Master / Slave - hanya lakukan ini ketika Anda telah memastikan bahwa beban penelusuran diserap oleh Varnish / FPC
- Bangun kembali templat
- Lepaskan mereka
- Pantau log akses secara terus menerus dan tulis ulang URL di Nginx / Varnish sebelum pengiriman. Jika melakukannya di level Nginx - pastikan Varnish melakukan caching pengalihan 301/302.
- Pisahkan konten statis ke CDN, atau tingkatkan konektivitas
- Tambahkan lebih banyak perangkat keras (well, kami harus mengatakannya di beberapa titik)
Jadi dengan ini dalam pikiran - Anda akan melihat mungkin tidak akan ada file konfigurasi Nginx, file konfigurasi PHP fcgi pool, file konfigurasi MySQL atau file konfigurasi Varnish yang akan sama. Berpasangan dengan perubahan perangkat keras itu sendiri; memori yang tersedia, kinerja I / O (HDD dan Jaringan) dan CPU - dan Anda akan menemukan ada variasi halus yang mengarah pada peningkatan kinerja 400% yang Anda inginkan - tetapi tidak ada satu jawaban cepat yang siap Anda temukan secara online.
Anda dapat menyalin + menempelkan kertas putih Magento yang disponsori Peer 1 pada kinerja (kami tidak akan merekomendasikannya); berharap pengaturan tidak melebihi memori yang tersedia, batas utas, status TCP / IP, kapasitas I / O dan mengarah pada kinerja yang lebih rendah daripada konfigurasi vanilla Apache / mod_php.
Jadi mari kita lanjutkan.
Tumpukan server Magento yang ideal
Ini lebih cenderung membuat Anda lebih dekat dengan kenyataan. Contoh yang baik untuk menunjukkan ini adalah untuk menunjukkan bagaimana Magento OS khusus dikonfigurasi, MageStack
Ambil sub-komponen yang terpisah dan Anda punya daftar perangkat lunak yang paling optimal / kritis, jika dikonfigurasi dengan benar , untuk menjalankan toko Magento. Terutama, khususnya, lebih-lebih:
Firewall, filter DOS, Load Balancer, Varnish, Nginx, PHP, Redis, Memcached, MySQL
Jadi ketika Anda bertanya:
Apa Pengaturan Server Magento Terbaik?
Apa tujuan Anda sebenarnya?
- Ketersediaan tinggi
- Keandalan
- Kesederhanaan administrasi
- Performa
- Skalabilitas
Cukup ceramah, bagaimana kita melakukannya
Untuk sebagian mencerminkan jawaban yang diberikan pada kesalahan server ke nada yang sama. Anda memiliki 3 server yang Anda inginkan - jadi pertama orientasikan mereka seoptimal mungkin. Kami akan menghindari solusi yang sangat tersedia karena jauh di luar cakupan jawaban ini.
Sub-komponen yang diperlukan untuk konfigurasi multi-server adalah:
- Firewall
- Load Balancer
- Server Web
- Server MySQL
- Penyimpanan umum
Jadi kita akan multi-guna beberapa sistem. Kepatuhan PCI-DSS menentukan peran, untuk setiap server. Jadi dengan 5 peran dan 3 server - Anda akan segera ditembus. MageStack mengatasinya dengan menggunakan virtualisasi - Anda bisa melakukan hal yang sama.
Server 1: Load Balancer + Server web
Server 2: Server web
Server 3: Server database
Tanpa latensi rendah dan bandwidth jaringan yang signifikan (> 1Gbps, <125μs), daripada memiliki penyimpanan umum - lebih baik bagi Anda untuk hanya menyimpan direktori root store pada setiap mesin dan mereplikasi data, baik secara real-time menggunakan ionotify
atau murtad menggunakan sebuah cron
pekerjaan. Sekali lagi, kami akan menghindari sistem file jaringan seperti NFS, atau perangkat blok yang direplikasi seperti Gluster atau DRBD - karena penyetelan luas dan bandwidth jaringan yang layak diperlukan.
Pernis harus duduk sedekat mungkin dengan bagian depan. Tetapi Varnish tidak dapat mendekripsi SSL. Jadi gabungkan dengan terminator SSL; Nginx, Pound, Stunnel, Stud, dll. Penyeimbang beban bawaan di Varnish tidak bagus - tetapi cukup untuk pengaturan 2 server.
Nginx + PHP-FPM baik-baik saja, tetapi jangan minum terlalu banyak bantuan kool Nginx. Ini akan melakukan hampir identik dengan konfigurasi Apache / mod_php tradisional, inilah beberapa bacaan yang baik tentang mengapa tidak menggunakan Nginx . Nginx bagus, memang sangat bagus, tetapi tentu saja itu bukan hambatan dari toko Magento - dan mengingat kompleksitasnya dan kurangnya dukungan Magento asli. Kebanyakan administrator sistem pemula akan mendapat manfaat dari menggunakan Apache / mod_php atas hal lain. Ini mungkin tampak seperti rekomendasi kuno menggunakan PHP-FPM - tetapi tes kinerja kami telah menunjukkan kinerja hanya ~ 7% lebih cepat dengan solusi Nginx - ketika dikonfigurasi dengan benar. Penyetelan dan pengalaman yang diperlukan untuk pengaturan Nginx / PHP-FPM yang berkinerja tinggi dan andal cukup luas untuk membuatnya mengungguli Apache / mod_php. Apa pun yang Anda pilih untuk digunakan, adalah panggilan Anda.
Server database sederhana, MySQL. Tetapi seperti yang disebutkan sebelumnya, jika Anda memiliki situs konversi tinggi, konfigurasi Master / Slave disarankan. Apakah Anda harus mengikuti pendekatan ini dapat ditentukan dengan membaca artikel ini .
Kemudian cache back-end perangkat Anda, Memcached dan Redis. Pada toko yang lebih kecil, menyimpan sesi dalam satu instance Memcache dan cache backend cepat di yang lain akan menghasilkan manfaat kinerja yang baik. Kami tidak menganjurkan menyimpan tag cache di backend lambat - karena menyebabkan lebih banyak masalah daripada yang diberikannya. Jadi dengan pengaturan Memcached, Anda harus kehilangan penandaan cache . Sebagai gantinya, kami menggunakan konfigurasi seperti ini .
Redis bukan asli dari Magento, tetapi dengan ekstensi dari Colin Mollenhour - ini adalah solusi yang lebih baik daripada Memcache, mendukung tag cache, penyimpanan sesi, dan bahkan penyimpanan cache persisten - ini tidak cukup volatile seperti Memcache . Tetapi memang ada kekurangannya. Kami telah menemukan di toko produksi skala besar (> 500 pesanan / jam,> 30rb uniques / jam) bahwa cache (dan tag) dapat terisi dengan sangat cepat dan begitu titik saturasi tercapai, mekanisme LRU agak gagal ( meskipun pengaturan berbeda) dan menyebabkan kemacetan langsung besar-besaran. Jadi bijaksana untuk memangkas secara teratur catatan lama secara manual.
Jadi perangkat keras apa yang harus digunakan untuk apa?
Server web: CPU Tercepat, sebagian besar inti CPU, rasio 2GB RAM / Core
DB server: CPU Cepat, I / O disk tercepat, sebagian besar RAM
Jadi ketika multi-purpose 3 mesin Anda, tata letak terbaik adalah:
Server 1: Terminator SSL -> Varnish -> Nginx / Apache> PHP
Server 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Server 3: MySQL
Mengenai konfigurasi spesifik dari setiap aplikasi. Nah, itu tergantung pada spesifikasi perangkat keras Anda, kompleksitas toko Anda, jenis dan sifat pengunjung Anda, dan banyaknya pengunjung.