Apakah Varnish tepat untuk Anda?
Varnish bukanlah kinerja Magento yang serba bisa dan paling akhir. Sangat bagus untuk mengimbangi muatan dari bot & pembeli di jendela - tetapi ini tidak seharusnya menjadi tempat panggilan pertama Anda untuk benar-benar membuat toko Anda lebih cepat.
Bahkan, menerapkan Varnish harus menjadi modifikasi kinerja terakhir ke toko Anda. Hanya masukkan sekali Anda melihat waktu pemuatan halaman yang Magento dapat berikan tanpa itu (mis. <600ms kali pemuatan halaman).
Toko Anda masih harus cepat
Karena Varnish masih membutuhkan setidaknya satu halaman memuat untuk mengunggah cache, itu berarti kinerja Anda yang belum di-cache masih harus sangat baik. Sebagian besar URL unik (klik navigasi berlapis, permintaan pencarian, dll.) Tidak akan pernah benar-benar dilayani dari Varnish kecuali:
a) TTL Anda sangat tinggi, sehingga permintaan pencarian dari 4 hari yang lalu masih berlaku hari ini
b) Footfall di situs ini sangat luas sehingga URL-URL tersebut diisi dalam waktu yang sangat singkat
Anda juga harus mempertimbangkan bahwa tidak setiap toko cocok untuk Varnish . Setiap situs yang mendorong pengguna untuk membuat sesi pribadi (mis. Masuk, tambahkan-ke-gerobak, dll.) Di awal perjalanan pelanggan mereka akan berarti bahwa Varnish pada akhirnya akan berlebihan.
Sebagai contoh, situs belanja pribadi mendorong pengguna untuk masuk dari pengaturan, namun, dalam melakukan ini, itu berarti bahwa Varnish tidak pernah benar-benar memiliki konten non-unik yang mampu cache. Jadi hit rate Anda akan sangat rendah dan tidak ada manfaat sama sekali dari menggunakan Varnish.
Konten segar atau tingkat klik yang lebih tinggi
Gambar milik magestack.com
Menggunakan Varnish secara efektif adalah tentang mencapai keseimbangan antara konten basi dan jumlah pengunjung di situs Anda.
Jika Anda memiliki situs yang sibuk - kemungkinan besar Anda bisa lolos dengan TTL yang lebih rendah dan masih memiliki hit rate Varnish yang tinggi - dan juga terus memiliki TTL yang rendah - dengan demikian, konten yang lebih segar. Jadi perubahan stok / harga Anda tercermin dengan cepat dan cache secara terus menerus diprima dari volume langkah kaki.
Jika Anda punya situs rendah lalu lintas - maka Anda akan harus membuat kompromi. Tingkatkan TTL Anda untuk memastikan tingkat klik yang lebih tinggi - atau memiliki konten terbaru. Anda tidak dapat memiliki keduanya. Ya, Anda dapat menjalankan alat crawl / spider secara terus menerus - tetapi sumber daya ini akan mengkonsumsi, dan semata-mata volume atau URL yang dapat dirayapi (biasanya dalam puluhan ribu untuk toko kecil ) berarti itu sama sekali tidak efektif. Jadi biasanya, toko yang lebih kecil akan mendapat manfaat lebih dari ekstensi FPC yang baik dan memiliki konfigurasi server yang sangat optimal.
Tapi tentu saja saya bisa menggunakan Varnish bahkan ketika pengguna masuk, bagaimana dengan cache per pengguna atau ESI?
ESI
ESI adalah utilitas yang sangat baik untuk dapat menyimpan konten dalam cache, dan masih dapat memiliki blok dinamis pada halaman. Tetapi agar dapat digunakan secara efektif, Anda harus meminimalkan jumlah panggilan balik hingga minimum. Ada sedikit modul head-start yang dapat Anda gunakan sebagai dasar untuk proses ini - pastikan Anda mengencangkan lubang keamanan di dalamnya, sangat tidak aman secara default - tidak ada batasan pada tata letak yang Anda bisa / tidak bisa muat
Setiap kali bootstrap Magento dimuat, ia datang dengan penalti kinerja sekitar 200 ms - sebelum bahkan memuat koleksi / merender blok dll. Jadi jika Anda memiliki lebih dari 3x ESI, kemungkinan besar Anda telah berakhir dengan waktu pemuatan laman yang lebih lambat menggunakan Varnish + ESI untuk konten dinamis, dari sekadar mem-bypass Varnish dan meneruskan permintaan langsung ke Magento sendiri.
Jadi untuk benar-benar menggunakan ESI secara efektif, Anda harus dapat menggabungkan beberapa permintaan dalam satu permintaan.
Misalnya, halaman tampilan kategori yang mencantumkan 20 produk perlu menunjukkan tingkat stok yang akurat. Jadi, Anda menggunakan ESI untuk setiap blok di halaman. Itu akan menjadi 20x permintaan saham ESI. Sementara permintaan stok sangat ringan, menjalankan 20x dari mereka secara bersamaan akan menghancurkan kinerja. Jadi sebagai gantinya, Anda bisa melayani seluruh blok / koleksi 20 produk dan hanya mendapatkan permintaan 1x itu. Tapi memuat dan merender koleksi mungkin adalah elemen paling lambat di halaman - jadi Anda belum mendapatkan banyak.
Menggunakan ESI secara efektif membutuhkan perencanaan dan pelaksanaan yang tepat, atau Anda akan memiliki situs yang lebih lambat daripada tidak menggunakan Varnish sama sekali.
Tembolok per pengguna
Lalu ada alternatif menggunakan cache khusus pengguna. Ini adalah ide yang buruk kecuali Anda memiliki situs dengan lalu lintas sangat rendah. Rasio hit Anda akan sangat rendah - karena peluang pengunjung untuk mencapai halaman yang sama dengan yang mereka kunjungi sangat rendah. Dan untuk setiap pelanggan, halaman 6Kb itu akan menempati lebih banyak ruang di tempat penyimpanan Varnish Anda.
Misalnya, jika Anda telah mengalokasikan 1GB ke Varnish. Dengan situs khas tempat pengguna melihat 8 halaman per kunjungan, rata-rata 6 halaman tersebut akan menjadi unik. Jadi itu adalah 28 pengunjung per 1MB penyimpanan. Kemudian faktor dalam gambar Anda, CSS dan JS - ini (untungnya) akan umum, tetapi mungkin masih akan menempati 7-800MB penyimpanan Anda yang tersedia. Ini membuat Anda memiliki sisa penyimpanan 200MB, cukup cache untuk 5.600 pengunjung unik.
Yah, aku tidak peduli, aku hanya ingin Varnish
Oke, maka Anda perlu melakukan hal berikut:
- Instal terminator SSL untuk duduk sebelum Varnish (mis. Stud / pound / nginx)
- Instal Varnish di server
- Pastikan Anda mengonfigurasi
X-Forwarded-Fordengan benar
- Instal modul Varnish di toko Anda
- Siapkan Varnish VCLs Anda untuk mengecualikan ekstensi pihak ketiga
Karena 3 poin pertama berada di luar cakupan jawaban ini, saya akan menyerahkannya sendiri kepada Anda. Poin 4 adalah permainan anak-anak dan dengan poin 5 - terus membaca.
Hal terpenting dari implementasi Varnish adalah memastikan bahwa Anda tidak pernah menembolok konten yang tidak boleh di-cache.
Misalnya.
- Callback gateway pembayaran
- Ikhtisar keranjang
- Pelanggan ikhtisar akun saya
- Checkout (dan masing-masing panggilan Ajax)
dll.
Untuk URL Magento inti, ada daftar URI yang cukup standar yang bisa Anda hindari di Varnish:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Tetapi Anda juga perlu mempertimbangkan ekstensi khusus / pihak ke-3 yang sedang Anda jalankan yang memiliki rute kustom, router, dan ruang nama. Sayangnya, tidak ada cara mudah untuk mengetahui URL apa dari ekstensi ini yang bisa dan tidak bisa di-cache. Jadi, Anda perlu mengevaluasi masing-masing berdasarkan kasus per kasus.
Sebagai aturan, setiap kali kita mengkonfigurasi Varnish, kita akan mulai dengan mengidentifikasi rute, router, dan ruang nama masing-masing yang mungkin mereka tempati dan pergi dari sana. Kami melakukan ini melalui SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Ini tidak akan memberi Anda daftar URL yang pasti - tetapi hampir pasti akan memberi Anda starter.
Kami tidak bisa menekankan betapa pentingnya untuk tidak pernah menyimpan konten yang seharusnya tidak di-cache. Hasilnya bisa menjadi bencana besar.
Singkatnya
Seperti halnya optimasi kinerja server Magento lainnya, diimplementasikan dan disetel dengan benar dapat benar-benar menghasilkan manfaat. Tetapi hanya dengan menjatuhkan perangkat lunak tanpa mengonfigurasikannya dengan benar, ini tidak hanya akan membuat toko Anda tidak lebih cepat, tetapi juga berpotensi lebih lambat, lebih tidak aman, dan kurang dapat diandalkan.