Kami hanya tidak - sama sekali. Pernah. Kami akan mengatakan ini berulang kali tetapi
Caching! = Performa
Situs Anda perlu untuk menjadi cepat tanpa penambahan FPC (atau Varnish untuk fakta bahwa). Akan selalu ada saat ketika konten tidak prima (skenario Anda di atas).
Di toko yang tidak dibongkar, waktu muat halaman dengan FPC seharusnya tidak lebih mengesankan daripada non-FPC; Magento cukup senang mampu < 400msmemuat halaman kali pada cache standar (pada kategori / produk / halaman pencarian). FPC akan membawanya ke < 80ms- tetapi dilengkapi dengan peringatan.
- Informasi stok / harga kedaluwarsa hingga tanggal valid atau TTL berakhir
Item baru / pencarian yang lebih relevan sudah kedaluwarsa hingga valid atau TTL berakhir
dll.
Mengapa mengandalkan FPC (atau Varnish) adalah A Bad Idea
Jika Anda ingin memastikan bahwa cache tersimpan secara manual, kemungkinan ada beberapa alasan
- Anda tidak memiliki cukup footfoot alami untuk menjaga cache tetap terjaga (lihat 'Di mana FPC berguna')
- Situs Anda terlalu lambat tanpa mereka
Anda tidak dapat menyimpan semuanya
Jika Anda mengambil toko dengan hanya 5 kategori, kedalaman 2 tingkat, bersarang 5 atribut yang dapat disaring, masing-masing 5 opsi atribut dan 1000 produk; itu banyak kemungkinan kombinasi.
25 opsi untuk dipilih, memilih satu hingga 5 kali berturut-turut - Saya bukan ahli statistik , tapi saya sadar itu ... (dengan asumsi jumlah opsi atribut tidak berkurang sepenuhnya)
25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5 possible URLs on the fifth selection
5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)
Ok, skenario di atas bukan skenario yang mungkin, seperti yang saya bayangkan, dalam 3 klik - jumlah produk yang tersedia akan berkurang cukup bagi pelanggan untuk menemukan produk mereka. Jadi bahkan jika itu ...
25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection
5^3 = 125 possible URL combinations
Kemudian dikalikan 5 kategori, yaitu 625 URL. Pada tahap ini, kita berbicara tentang katalog kecil, dan sepenuhnya mengabaikan semua URL produk.
Kami juga tidak mempertimbangkan bahwa jika Anda memiliki kategori bersarang dengan is_anchor, itu akan meningkat secara eksponensial.
Jadi untuk merayapi volume halaman itu - Anda harus berharap bahwa waktu buka halaman Anda bagus dan rendah untuk memulai, sehingga ini adalah proses yang ringan cepat (sehingga mengalahkan tujuan perayapan) - atau bahwa Anda memiliki cukup waktu untuk menyelesaikan sebelum TTL berakhir.
Jika halaman Anda memiliki waktu buka halaman 0,4 detik dan Anda memiliki CPU 8 inti - maka ...
625 * 0.4 = 250 / 8 = 31 seconds
0,5 menit, tidak buruk - tetapi mari kita bayangkan Anda memiliki waktu memuat halaman 2s
625 * 2 = 1250 / 8 = 156 seconds
Tetapi jika Anda mengambil skenario semaksimal mungkin
3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes
Jadi itulah server produksi Anda, di bawah 100% beban CPU selama 15 menit. Anda akan mengurangi kecepatan perayapan secara proporsional ke TTL yang Anda inginkan.
Jadi jika Anda ingin konten memiliki TTL 3600, perayapan bisa 4 kali lebih lambat - yaitu. hanya 25% CPU yang didedikasikan untuk perayapan. Itu banyak sumber daya hanya untuk menjaga konten kategori prima - kami bahkan belum memperhitungkan produk, istilah pencarian atau tampilan toko tambahan pada tahap ini
Faktanya, hanya dengan melihat ukuran kombinasi yang sebenarnya dalam catalog_url_rewritestabel (yang bahkan tidak memfaktorkan parameter dari navigasi berlapis) akan memberikan gambaran tentang berapa banyak URL yang bisa Anda perlu perayapi.
Setiap toko pasti akan berbeda, tetapi yang ingin saya lakukan adalah merayapi situs ke FPC utama tidak praktis. Pastikan toko Anda cepat untuk memulai .
Di mana FPC berguna
Di mana manfaat FPC ikut bermain adalah di toko yang sarat muatan - di mana Anda memiliki tingkat lalu lintas yang benar-benar tinggi dan cache secara alami dan terus-menerus dipupuk oleh kekalahan semata-mata saja.
FPC kemudian ikut bermain dengan mengurangi overhead infrastruktur pada konten yang biasanya diminta - mengurangi panggilan berulang ke backend Magento.
Jadi kami menemukan bahwa FPC bagus untuk digunakan ketika Anda memiliki tingkat lalu lintas yang sangat tinggi - bukan untuk mengurangi waktu buka halaman - tetapi untuk mengurangi penggunaan sumber daya.
Siapa peduli, saya masih mau merangkak
Nah, maka Anda punya dua opsi
- Merayapi dari templat (Mis. Sitemap)
- Ekstrak halaman demi halaman dan rangkak setiap tautan
Dan ada banyak utilitas untuk melakukan keduanya, ini adalah beberapa yang saya ketahui
- mage-perftest
- HTTrack
- Nutch
- Sphider
- Crawler4j
Menggunakan Mage-Perftest
Anda dapat menjelajah toko Anda dengan Mage-Perftest dengan cukup mudah, pertama unduh itu
wget http://sys.sonassi.com/mage-perftest (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386 (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*
Kemudian tentukan proses perayapan menggunakan peta situs Magento (Anda dapat menyesuaikan ini dengan membuat peta situs URL apa pun, asalkan url dibungkus dengan <loc></loc>tag). Perintah berikut akan membaca semua URL dari file sitemap, kemudian merangkak (hanya PHP) URL selama 1440 menit (1 hari). Jika server melebihi 20% CPU atau rata-rata memuat 2 - perayapan akan berhenti sementara.
./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2
Jika Anda memiliki 1000 URL, dirayapi lebih dari 1 hari, itu akan menjadi sekitar. 1 permintaan setiap 86 detik ~ target 0,011 RPS