Masalah kinerja dengan situs / toko 1k hingga 10k


9

Saya mencoba mencari cara untuk meningkatkan kinerja Magento ketika jumlah situs web / toko melebihi 1k, dan tujuan saya adalah sekitar 10k. Inilah beberapa pertanyaan; setiap tips / bantuan sangat welcome!

  1. Menambahkan situs / toko baru lambat;
    Saya berkomentar $ this-> cleanModelCache () di _afterSave () di Mage_Core_Model_Abstract, dan situasinya tampak lebih baik tetapi semakin lambat dengan meningkatnya jumlah situs web / toko. Dan saya tidak tahu apa yang akan mempengaruhi seluruh sistem di masa depan.

  2. Panggilan api menjadi lambat.
    Salah satu proses utama adalah melakukan pemesanan; model khusus saya berurusan dengannya dengan memproses beberapa data, dan pada dasarnya menggunakan model penjualan / penawaran dan model penjualan / service_quote. Prosesnya dimulai dengan Oauth. Oauth dan penempatan pesanan membutuhkan waktu lebih lama ketika jumlah situs web / toko bertambah, dan konsumsi memori tampaknya lebih besar. Apakah ini ada hubungannya dengan Mage memuat konfigurasi xml, dan fakta bahwa data konfigurasi semakin besar dengan semakin banyaknya situs web?

  3. Membuka n98-magerun dev: konsol lebih lama; tidak tahu penyebabnya.

  4. Menyimpan konfigurasi dari panel admin membutuhkan waktu lebih lama; tidak tahu bagaimana memperbaikinya.

Apakah mungkin untuk merekonstruksi cara Magento menghasilkan dan memuat data konfigurasi untuk menurunkan konsumsi memorinya? Apakah ini salah satu faktor yang menyebabkan masalah kinerja untuk situasi saya?

Contoh Magento saat ini: Versi = Magento EE 1.14.2.4;
Konfigurasi cache aktif; cache lainnya tidak aktif;
Menggunakan Mysql 5.6 dan MongoDB (untuk catalog_category_entity, catalog_product_entity, core_website);
jumlah situs web = jumlah toko = jumlah tampilan = 1024;
jumlah produk = 4501;

Terima kasih sebelumnya!


2
mengapa dukungan magento tidak dapat membantu Anda ???
MagenX

Bagaimana saya mendapat bantuan dari mereka? Saya baru mengenal komunitas .. terima kasih!
Jack.W

1
Anda memiliki versi perusahaan, tidak yakin dari mana Anda mendapatkannya, tetapi jika tidak ada dukungan magento di belakangnya, buang uang dan waktu saja. Anda harus memukul mereka dengan baik untuk membuatnya berlari seperti kelinci membantu Anda. apa gunanya memiliki versi perusahaan ???
MagenX

1
tetapi jawaban yang jelas untuk pertanyaan Anda adalah - toko
magento

Ah benar .. Saya akan meminta akun bos saya..haha.
Jack.W

Jawaban:


3

Salah satu alasannya menjadi lambat adalah karena konfigurasi untuk setiap toko diduplikasi dari / config / situs web dan / config / global dan kode untuk melakukan itu tidak efisien. Setiap perubahan pengaturan mungkin berakhir menyebabkan beberapa 10 menit, jika bukan jam, dari penurunan kinerja dan throughput. Menjadikannya lebih efisien pada dasarnya berarti Ben Marks akan mengejar Anda ... dan tidak dengan cara yang baik.

JIKA Anda akan turun rute ini, cara termudah adalah dengan memiliki 10k instalasi Magento dan memiliki semacam broker yang mendelegasikan permintaan ke situs web yang sesuai. Meskipun itu, tentu saja, tergantung pada apa use case Anda sebenarnya.

[ditambahkan]

Bergantung pada use case Anda mungkin dapat menggunakan kategori sebagai pseudo store. Anda bisa secara teknis menggunakan layout XML untuk mengubah tema per toko. Tapi kemudian Anda akan mengalami keterbatasan checkout. Semua toko perlu membagikan checkout.

Either way, toko 10k Magento bisa dilakukan, karena itu bukan tidak mungkin. Tapi itu akan menjadi jalan yang sulit, jalan apa pun yang Anda pilih.


Hai Kevin, terima kasih atas balasan Anda! Ya saya melihat kode yang memperbarui pohon konfigurasi, yang merupakan loadToXml () jika saya tidak salah. Pikiranku adalah; dan Anda mengatakan itu bukan ide yang baik untuk memodifikasinya? Apa maksudmu dengan Ben Marks yang mengejarku? Juga, tampaknya setiap permintaan http yang datang ke Magento akhirnya akan memuat pohon konfigurasi, apakah itu benar? Bagaimana saya bisa mengecilkan ukurannya? Saya mungkin harus berpikir tentang mendapatkan 10k Magento instance ... ada pemikiran tentang berapa banyak sumber daya yang akan dibutuhkan? Kevin terima kasih banyak!
Jack.W

Tetapi memiliki 10k instalasi Magento berarti 10k contoh mysql, kan? Saya tidak tahu bagaimana melakukan ini, atau jika itu adalah ide yang bagus ..
Jack.

1
Tidak, itu berarti memiliki 10k database mysql, tetapi semua 10k dari mereka bisa dalam satu contoh mysql.
Christian

1
"Ben Marks" datang setelah Anda adalah referensi ke camo.githubusercontent.com/...
Kevin Schroeder

1
Instalasi 10k Magento berarti 10k database MySQL, namun itu akan tersebar. Akan jauh lebih mudah untuk skrip menggelar 10k instalasi Magento individu daripada membuat kode inti yang ada berfungsi dengan 10k toko.
Kevin Schroeder

1

Anda dapat mencoba meretas inti dan mengaktifkan pemisahan cache situs web. Anda dapat mencoba meretas basis data dan menyimpan informasi konfigurasi dalam memori. Anda dapat mencoba mengganti cache konfigurasi dengan sesuatu yang lebih pintar - katakanlah caching informasi dari file xml [yang statis dan berlaku untuk semua situs web dan toko] sambil mengambil alih data secara dinamis.

Saya seorang pria server, jadi saya akan pergi dengan mucking dengan database. Terutama karena itu sepele untuk dilakukan.

Jika Anda memiliki kendali atas server basis data Anda: Ganti nama tabel core_config_data menjadi core_config_data_offline Buat tabel core_config_data baru menggunakan mesin penyimpanan MEMORY http://dev.mysql.com/doc/refman/5.7/id/memory-storage-engine.html Salin semua data dari core_config_data_offline ke core_config_data

Setup pekerjaan cron untuk memeriksa untuk melihat apakah core_config_data ada, jika itu menyalin semua data dari sana ke core_config_data_offline. Jika tidak, buat dan salin semuanya dari core_config_data_offline ke core_config_data

Matikan cache config. Dengan cache konfigurasi diaktifkan, Anda hanya mendapatkan peningkatan kinerja untuk pertama kali data konfigurasi dibaca dari database - setelah itu ada dalam cache dan Anda menderita. Pada sisi negatifnya, file xml tidak lagi di-cache, jadi Anda memperdagangkan hit kinerja unserialisasi data konfigurasi besar untuk hit kinerja dari penguraian banyak file xml.

Anda mungkin juga ingin bereksperimen dengan mengubah file Mage / Core / Model / Config.php dan mengaktifkan cache masing-masing situs web. Secara default setiap menyimpan data konfigurasi khusus di-cache secara individual. Semua data konfigurasi situs web di-cache dalam satu objek.

Perhatikan bahwa ini hanya untuk konfigurasi yang menimpa [pengaturan admin]. Jadi, jika Anda melakukan semua perubahan konfigurasi di tingkat toko yang sudah Anda atur. Jika Anda menggunakan "warisan dari situs web" dan membuat sebagian besar perubahan konfigurasi khusus toko Anda di tingkat situs - maka cache berisi setiap situs web. Dengan membaginya, Anda dapat memecahkannya lebih baik. protected $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'store' => 1, 'websites' => 0);

untuk

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
); 

Hai Gary, terima kasih atas balasan yang sangat membantu! Saya punya beberapa pertanyaan: 1) Dari pengamatan saya, permintaan basis data tidak menjadi masalah, bahkan dengan lebih dari 1k situs web / toko; jadi jika itu masalahnya, apakah menggunakan penyimpanan memori masih membantu? 2) Saya tidak tahu apakah itu benar, tetapi cache konfigurasi sepertinya hanya menyimpan informasi sistem dan modul; jadi apakah itu ada hubungannya dengan konfigurasi situs web / toko? 3) Apakah ada cara agar magento mengenali toko / id situs web tertentu dari permintaan http, dan karenanya hanya memuat file konfigurasi yang sesuai? Terima kasih banyak, Gary!
Jack.W

2
Rekomendasi ini tidak mengatasi masalah yang diperhatikan OP. Mematikan cache konfigurasi pada akhirnya akan mematikan sistem. Ini akan menyebabkan Magento memuat semua file konfigurasi, menggabungkannya, kemudian menggabungkan semua / global lalu menggabungkan semua / situs web dan kemudian menggabungkan semua itu ke dalam masing-masing / menyimpan node. Itu akan terjadi untuk setiap permintaan. Dengan 10k situs Anda bisa melihat menit waktu jam dinding per permintaan .
Kevin Schroeder

Hai Kevin, terima kasih atas jawabannya; Sebenarnya saya berencana untuk memindahkan tabel core_config_data ke dalam memori, mengaktifkan cache untuk konfigurasi sistem dan modul, menghentikan core_config_data agar tidak digabungkan ke pohon konfigurasi, dan membuat fungsi yang membaca bagian data ini secara langsung meminta dari database. Bagaimana menurut anda?
Jack.W

1
Masalahnya bukan core_config_data. Masalahnya adalah bahwa konfigurasi toko digabung dari / situs web yang digabungkan dari / global dalam XML. Basis data akan baik-baik saja. Ini adalah PHP yang akan membenci kehidupan karena penggabungan konfigurasi. Dalam langkah debugger Anda melalui Mage_Core_Model_Resource_Config :: loadToXml memberikan perhatian khusus pada baris 110 dan berikut
Kevin Schroeder

1
Sekarang untuk kembali ke meja ingatanku. Caching data berarti menyimpannya di suatu tempat yang dapat diakses dengan cepat. Magento melakukan cache data konfigurasi ke objek serial php - jika data konfigurasi Anda sangat besar itu berarti PHP harus membatalkan deserialisasi sejumlah besar data untuk setiap permintaan. Jika Anda tahu cara menggunakan xdebug, buat profil dari beberapa halaman Anda yang lebih lambat memuat dan lihat berapa banyak waktu yang dihabiskan untuk menjalankan fungsi unserialize: php.net/manual/en/function.unserialize.php - jika itu sangat besar [lebih dari 100 ms] maka "caching" konfigurasi ini merusak sistem Anda.
Gary Mort
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.