Solusi permanen untuk masalah pengindeksan umum

23

Kami telah mengembangkan beberapa proyek magento dengan catatan inventaris yang besar dan selalu menghadapi masalah pengindeksan, kami telah mencoba segala hal yang ditemukan di internet untuk memecahkan masalah pengindeksan sehari-hari seperti memotong tabel datar dan mengindeks ulang menggunakan CLI, mengatur cron untuk pengindeksan tapi ini adalah sakit kepala kita sehari-hari menghadapi masalah pengindeksan.

Kami mencari solusi Permanen untuk masalah ini sementara kami mengerjakan proyek ada skenario berbeda seperti memperbarui produk setiap hari atau mengimpor produk dari beberapa feed lain setiap hari.

Siapa pun yang memiliki praktik terbaik dengan ini atau beberapa solusi, silakan bagikan yang akan sangat dihargai.

— ravisoni
sumber

Saya telah menghabiskan satu tahun di Magento dan ekstensi dan arsitektur data yang sangat tidak efisien dan bodoh yang membuat situs e-commerce dengan hanya 10K plus produk omong kosong. Semua peringatan ini seharusnya diberikan kepada siapa pun yang mulai melihat Magento CE. Magento onwers harus dibawa ke pengadilan karena menghabiskan ribuan jam kerja. Biarkan saja database melakukan pengindeksan, jangan melakukan pekerjaan database. Saya menyarankan agar daripada membuang-buang uang di server khusus dan kemudian berjam-jam tidur tanpa tidur, lebih baik pindah ke platform e-niaga yang di-hosting atau sumber terbuka yang menggunakan MS SQL server.

— semiprecious.com

Pernahkah Anda berpikir bahwa mungkin Anda tidak menemukan ekstensi yang tepat, atau konfigurasi server yang tepat? Jika beberapa perangkat lunak tidak sesuai dengan kebutuhan Anda tidak selalu berarti itu tidak berguna. Saya telah mendapatkan roti (dan bir) selama 5+ tahun terakhir dari Magento dan saya juga memiliki banyak pelanggan yang puas. Beberapa dengan katalog lebih dari 10k.

— Marius

Mereka benar, karena cara CE bekerja pemeliharaan data adalah masalah dengan 10 hingga 100 ribu skus. EE lebih baik karena pembaruan pengindeksan yang telah mereka buat tapi itu untuk $ mulit-juta perusahaan pendapatan. Anda dapat melakukan hosting tetapi Anda akan mengubah ROI negatif. Solusi yang kami gunakan sangat khusus & proses delta yang diunggah mirip dengan solusi seperti penggunaan SAP & Walmart, dikombinasikan dengan solusi penetapan harga khusus (ATG-esque) yang memintas masalah pengindeksan (fx & inline margin / atribut recalcs), dikombinasikan dengan kluster hosting Jawaban sederhana tidak, Magento tidak dirancang secara optimal.

31

Penting untuk memahami indeks apa yang lambat dan mengapa

Kompleksitas katalog dan akhirnya arsitektur toko akan menentukan berapa lama pengindeksan ulang - dikombinasikan dengan infrastruktur yang mendasarinya.

Jika Anda memiliki 50.000 produk dan 10 tampilan toko, Anda dapat menjamin beberapa juta baris catalog_url_rewriteakan membutuhkan waktu untuk diproses.
Jika Anda memiliki 100 produk, tetapi 5.000 atribut, Anda dapat menjamin catalog_attributesatau catalog_product_flattabel akan membutuhkan waktu lama untuk dibangun kembali, atau jatuh datar di wajahnya
Jika Anda memiliki 1.000 produk, tetapi 500 atribut yang dapat dicari, maka catalog_fulltext_searchperlu waktu untuk menyelesaikannya

Solusi untuk masing-masing dan setiap masalah yang Anda hadapi tidak 1 ukuran cocok untuk semua, ini tentang merancang toko Anda dengan benar; memiliki infrastruktur yang tepat untuk mendukungnya dan menggunakan frekuensi / strategi indeks ulang yang keduanya mendukung kebaruan konten dan kinerja.

Menambahkan caching front-end tidak akan membantu sama sekali
Melempar lebih banyak perangkat keras pada situasi itu mungkin
Mengatasi ukuran / kompleksitas katalog akan membantu
Menggunakan alat pengindeksan pihak ketiga akan membantu
Eksternalisasi indeks tertentu (mis. Pencarian> SOLR) akan membantu

Ada juga kasus mengevaluasi apakah indeks tertentu bahkan diperlukan. Menggunakan produk / kategori flat tidak selalu membuat semua toko lebih cepat; kami telah melihatnya membuat toko jauh lebih lambat. Jadi, Anda mungkin menemukan bahwa setelah menguji kinerja sebelum / sesudah - mereka bahkan tidak menjadi pertimbangan.

— Ben Lessani - Sonassi
sumber

8

tl; dr

Tidak ada solusi peluru perak. Ada beberapa solusi, saya sarankan Sonassi_Fastsearchindex- tapi itu khusus untuk pencarian katalog.

Mungkin menonaktifkan pembaruan indeks pada save - penjadwalan untuk menjalankan semalam - akan memberikan beberapa bantuan? Dikombinasikan dengan menambahkan lebih banyak caching - memcached, Redis, APC - dan cache satu halaman penuh seperti Varnish (jika Anda menjalankan CE) dapat membantu Anda memulai. Jika Anda berencana menggunakan Varnish, lihat di Nexcess_Turpentinegithub untuk memulai lebih cepat.

Informasi lebih lanjut

Masalah pengindeksan - khususnya catalog_url_rewrites - diketahui dan didokumentasikan dalam komunitas. Magento telah menangani ini dalam versi Perusahaan karena ini adalah pelanggan yang paling terpengaruh. Banyak pelanggan EE memiliki produk 10k + dan beberapa tampilan toko, situs web, dll.

Namun, jika Anda memiliki katalog besar dan sejumlah besar atribut Anda mungkin menemukan diri Anda dalam posisi bahwa pengindeksan akan memakan waktu lama - khususnya catalog_url_rewrite, product_flat - dalam hal ini saran saya adalah jangan memperbaiki waktu menjalankan indeks. panjang tetapi lebih untuk membongkar beberapa pemrosesan untuk memungkinkan kotak untuk menghabiskan siklus pengindeksan CPU daripada melayani konten .

Pertanyaan untuk diri sendiri:

Apakah saya kehilangan bisnis karena masalah pengindeksan?
Apakah saya kehilangan produktivitas karena masalah pengindeksan?
Apakah saya berisiko kehilangan konversi atau apakah tingkat konversi saya menderita?
Apakah pelanggan saya berisiko membeli barang yang tidak tersedia yang merupakan akibat langsung dari indeks yang tidak sinkron (inventaris, dll.)
Apakah aturan penetapan harga katalog saya bagian dari bisnis inti saya dan
Apakah tingkat konversi di tempat-pencarian saya lebih tinggi dari biasanya (8-10%), sehingga mendapat manfaat dari pengindeksan yang lebih baik?

Tidak ada solusi peluru perak untuk masalah khusus ini - sebagai penyedia solusi Anda harus membantu pelanggan Anda membuat keputusan yang akan meningkatkan penjualan dan bisnis terbaik sambil menjaga biaya overhead tetap rendah.

Alternatif

Pencarian katalog offload dan layered nav ke Solr.

Skala secara horizontal. Tambahkan lebih banyak server Apache / nginx. Lebih banyak server = lebih banyak throughput bersamaan. Ini bukan 1: 1. Nexcess memiliki whitepaper yang bagus untuk kinerja dan konfigurasi Apache di sini: http://www.nexcess.net/magento-best-practices-whitepaper

Dan, jika Anda memilih untuk menggunakan Varnish - ingat:

masukkan deskripsi gambar di sini

— Philwinkle
sumber

Kami menghargai alat peraga, tetapi pengindeksan ulang tidak ada hubungannya dengan caching front-end; sepenuhnya merupakan operasi back-end. Mengurangi beban front-end akan mencegah pengindeksan ulang membutuhkan waktu lebih lama, tetapi tentu saja tidak akan membuatnya lebih cepat.

— Ben Lessani - Sonassi

Apa yang saya maksudkan adalah mengurangi lalu lintas yang datang ke kotak. Perhatian utama di sini adalah situs menjadi tidak tersedia selama indeks atau dikunci untuk periode waktu yang tidak diketahui saat pekerjaan berjalan. Pada akhir hari jika pengindeksan tidak memiliki efek negatif pada frontend, tidak masalah berapa lama pekerjaan berjalan. Tidak ada perbaikan atau peningkatan pada waktu muat pengindeksan. Tidak ada yang menginginkan jawaban "Tingkatkan ke versi berbayar" - jadi saran saya adalah meningkatkan ketersediaan frontend Anda dan menjadwalkan indeks untuk keluar dari puncak.

— philwinkle

Tentu saja, saya mengerti bahwa - tetapi ketersediaan sementara penting untuk situs web; itu tidak cukup untuk situs e-commerce. Jika Anda tidak dapat benar-benar melakukan pembelian karena indeks dikunci, maka situs tersebut mungkin juga offline.

— Ben Lessani - Sonassi

kami hanya memiliki beberapa ratus produk dan masih butuh beberapa menit untuk menyimpan produk sederhana di Magento 1.7, dan saya membayar lebih dari $ 500 sebulan untuk server Rackspace khusus. Saya tidak yakin harus mulai dari mana, tetapi saya menduga beberapa indeks mungkin rusak. Adakah yang bisa merekomendasikan konsultan magento yang baik?

— Max Hodges

5

Di sebagian besar webshop Magento berat, sebagian besar sangat sulit untuk membuat Manajemen Indeks backend Magento berfungsi. Saya sering mengalami masalah ini. Menjalankan skrip shell sepanjang waktu oleh pengembang seringkali sibuk. Biasanya saya memperbaiki masalah ini secara permanen seperti ini.

Saya membuat salinan baru shell / indexer.php> shell / myindexer.php

Kustomisasi shell / myindexer.php di sekitar baris 154

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

Untuk

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

dan, tambahkan pemeriksaan ini di sekitar baris 166

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

sebelum

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

Dan kemudian saya menambahkan skrip shell baru ke cpanel cron untuk dijalankan setiap 5 menit

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

Seperti script shell di atas berjalan setiap 5 menit dan hanya proses pengindeksan ulang yang membutuhkan pengindeksan ulang, itu mengurangi risiko beban berat ke server cpu serta seluruh proses pengindeksan ulang sangat cepat. Jika tidak ada proses yang memerlukan pengindeksan ulang, itu tidak akan menjalankan proses pengindeksan ulang. Juga, ingatlah untuk menempatkan mode pengindeksan ulang ke "Update on Save" di halaman Manajemen Indeks. Jika Anda tidak tahu, Anda bisa mendapatkan opsi ini di Tindakan> Ubah mode indeks di sebelah tombol Kirim.

— rbncha
sumber

@ Berganti, selamat datang. Aku senang itu sepadan denganmu.

— rbncha

Saya telah memasukkan ini ke dalam skrip saya, kalau-kalau ada yang merasa berguna: gist.github.com/steverobbins/…

— Steve Robbins

4

Akan lebih mudah untuk mengatakan jika Anda bisa memberikan lebih banyak data (ukuran inventaris, pengunjung, mesin), tetapi di sini ada kemungkinan:

kami menggunakan Sonassi_Fastsearchindexekstensi untuk indeks pencarian katalog. Meskipun hanya mengindeks judul, deskripsi, dan sku (saya pikir saya perhatikan), ini berfungsi dengan baik dan mengurangi waktu pencarian indeks katalog.
kemungkinan besar ada beberapa pengindeks yang tidak harus Anda jalankan, misalnya untuk tag atau atribut produk. Kadang-kadang cukup jika Anda hanya melakukan harga, flat produk, kategori produk dan pencarian katalog secara teratur, dan yang lainnya mungkin setiap hari.
kami menyinkronkan produk dengan sistem eksternal setiap dua jam, dan sementara itu, kami mengindeks dengan skrip php. Jadi, kami memiliki cronjob untuk setiap pengindeks yang ingin kami jalankan pada waktu tertentu, dan biarkan cron ini menjalankan skrip. Ini tampaknya merupakan jalan tengah terbaik antara apa yang dapat dilakukan server dan data produk terbaru.

Ini berjalan pada Magento CE 1.7.0.2; masih terasa sakit;)

— simonthesorcerer
sumber

Kami umumnya menghadapi masalah dengan produk rata semua indeks lainnya baik-baik saja.

— ravisoni

3

menggunakan Dnd_Patchindexurl, saya dapat memotong waktu indexindex_url_rewrite hampir 70%

Saya pikir ini adalah solusi yang bagus untuk mengecualikan produk yang dinonaktifkan atau produk yang tidak terlihat agar URL mereka dibuat tanpa biaya!

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

Setelah:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

Saya menginstalnya pada 1.9.1.1 dan bekerja dengan sangat baik!

Dapat diinstal melalui Connect juga http://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/

— web maurisource
sumber

1

Tingkatkan ke EE 1.13. Pengindeks sangat ditingkatkan dalam versi ini.

— Paul Grigoruta
sumber

2

Tetapi kebanyakan klien lebih suka versi komunitas.

— ravisoni

1

Sepakat. 1.8 akan keluar dalam beberapa minggu tetapi kemungkinan besar tidak akan termasuk optimasi pengindeks. Saya juga tidak suka, tapi ini adalah cara termudah, teraman dan mungkin termurah untuk membuat pengindeks Anda tampil.

— Paul Grigoruta

apakah ini mustahil untuk menemukan solusi permanen.

— ravisoni

Dalam kebanyakan kasus, di mana seseorang memiliki begitu banyak SKU sehingga mereka benar-benar berlari ke dinding bata dengan pengindeks CE 1.7 yang ada, maka mereka harus pergi dengan EE 1.13. Ada banyak situs yang berjalan lancar di luar sana dengan CE 1.7 dan pengindeks EE 1.12 ini memiliki SKU 10-25k. Kuncinya adalah mengelola mereka pada tingkat alur kerja sebagian besar dan memiliki infrastruktur yang tepat.

— davidalger

CE adalah pilihan yang sangat memadai. Fitur - fitur di EE 1.13 adalah perbaikan bug - yang telah didorong oleh komunitas ke CE. Terlepas dari itu dan terlepas dari apakah Anda menggunakan CE atau EE - waktu pengindeksan akan selalu sepenuhnya tergantung pada kompleksitas katalog, konfigurasi server, konkurensi pengunjung, dan frekuensi indeks ulang. EE bukanlah peluru ajaib, dan tentu saja bukan solusi yang tepat untuk masalah terkait arsitektur apa pun.

— Ben Lessani - Sonassi