Bagian mana dari lapisan model yang dapat dilewati untuk kepentingan optimasi kinerja


28

Saat ini saya melihat bahwa untuk tabel database dengan skema yang sangat sederhana (sekitar 5 bidang), ini memasukkan catatan baru pada tingkat di bawah ~ 50 sisipan / detik, di lingkungan pengembangan lokal saya (drive SSD) - ini adalah dengan tidak ada pengamat pada model yang mengisi tabel terkait

Menggunakan SQL langsung saya melihat peningkatan yang cukup - ~ 1800 menyisipkan / detik. Kami sedang memikirkan upaya untuk mengoptimalkan kinerja model kami, tetapi tentu saja kami tidak ingin kehilangan semua stabilitas dan fleksibilitas yang bagus yang diberikan oleh inti Magento kepada kami.

Saya bertanya-tanya apakah seseorang telah menempuh rute ini sebelumnya dan apakah ada beberapa kemenangan mudah dalam hal komponen lapisan model yang dapat dilewati secara relatif aman yang akan memberikan peningkatan kinerja yang signifikan.

Hal-hal seperti:

  • Resolusi nama kelas
  • sebelum dan sesudah menyimpan acara
  • Pengiriman acara
  • Transaksi
  • dll.

UPDATE: Saya berbohong, sebenarnya ada beberapa pertanyaan tambahan yang memunculkan pengamat atau afterSave (), yang saya lihat ketika saya memeriksa log kueri basis data. Benchmarking terhadap entitas yang benar-benar sederhana sebenarnya memberi saya ~ 300 baris / detik dengan model Magento - hanya overhead MySQL yang merupakan transaksi.


1
Sudahkah Anda mencoba menggunakan kembali objek model untuk menulis data? Yaitu menghapusnya, setData dan kemudian simpan. Ini akan menghindari panggilan ke getModel dan overhead objek instantiation yang melekat pada PHP.
davidalger

Juga, saya akan menebak bahwa kemacetan di sini adalah di CPU Anda dan bukan drive ... karena semua file kode yang diperlukan akan dimuat pada pass pertama.
davidalger

Terima kasih, David! Saya akan mencobanya juga. Sebenarnya saya pikir kita masih I / O terikat oleh jumlah permintaan yang dieksekusi. Kami memiliki sekitar 20 pertanyaan yang berjalan untuk menyimpan model yang diberikan - beberapa di antaranya perlu kami pertahankan (mengisi tabel terkait, SELECT untuk memeriksa keberadaan sebelum disimpan), dan yang lain yang mungkin dapat kami hapus (hemat sesi tambahan, beban tambahan () yang dapat dihindari dalam logika aplikasi)
kalenjordan

Anda bisa dengan mudah mengetahuinya. Pasang dir root keseluruhan dan MySQL DB pada disk RAM. Tapi saya akan sangat meragukan I / O adalah masalah dalam peralatan server grade. Anda mungkin akan melihat lebih banyak manfaat hanya dengan menonaktifkan "Index on Save".
Ben Lessani - Sonassi

Jawaban:


17

Satu hal yang dapat mempercepat seluruh situs adalah menghapus semua referensi Varien_Profilerdi situs produksi Anda. Bahkan jika profiler dinonaktifkan, ia selalu memeriksa apakah diaktifkan sehingga setiap panggilan Varien_Profiler::akan menghasilkan ifpernyataan tambahan . Tentu saja, menghapus semua panggilan ini dilakukan dengan biaya tidak dapat menggunakan profiler lagi. Namun, ini dapat mempercepat seluruh situs sekitar 5% atau lebih (ini adalah pengalaman subjektif, tetapi ada banyak BANYAK panggilan ke Varien_Profilerseluruh Magento). Saya sebenarnya menulis skrip shell kecil untuk secara otomatis mengomentari panggilan ini di semua file dan saya akan menambahkan ini ke posting saya besok ketika saya sedang bekerja dan memiliki kode saya siap.

Seperti yang dijanjikan sekarang, kode untuk mengomentari panggilan ini:

grep -l "Varien_Profiler" * -R > profiler.txt 
for x in `cat profiler.txt` 
do 
sed -i '/Varien_Profiler/s/^/\/\//' $x
done

Ini harus dijalankan di konsol linux baik di app / maupun di lib / folder. Anda mungkin perlu menyesuaikan file /lib/Varien/Profiler.php secara manual sesudahnya. Juga perhatikan bahwa Anda harus menguji ini secara menyeluruh di lingkungan yang aman sebelum membawanya langsung - tapi saya kira ini harus jelas;)


Wow! Saya tidak akan pernah membayangkan sesuatu yang mendekati 5% hanya untuk panggilan Varien_Profiler saat dinonaktifkan. Saya akan memeriksanya, terima kasih!
kalenjordan

@ sparcksoft Seperti yang dijanjikan, saya menambahkan kode sekarang.
mpaepper

1
Di situlah kondisi C precompiler sangat bagus. Sayang sekali PHP tidak memilikinya, tetapi tentu saja, itu berarti harus memiliki metode pra-kompilasi dan caching bawaannya sendiri. :)
davidalger

2
Anda juga dapat menulisnya find . -type f -exec grep -qF 'Varien_Profiler' {} \; -exec sed -i '/Varien_Profiler/d' {} \;jika Anda lebih suka oneliner cepat.
kojiro

14

Saat menjalankan banyak penghematan pada model Magento, yang terbaik adalah menonaktifkan pengindeks Magento yang memperlambat proses:

$processes = Mage::getSingleton('index/indexer')->getProcessesCollection();
$processes->walk('setMode', array(Mage_Index_Model_Process::MODE_MANUAL));
$processes->walk('save');

Dan mengaktifkannya saat Anda selesai:

$processes->walk('setMode', array(Mage_Index_Model_Process::MODE_REAL_TIME));
$processes->walk('save');

Ah paham, bagus. Jadi itu akan seperti jika Anda menyimpan banyak catatan customer_entity dan ingin menghindari terjadi pengindeksan pelanggan untuk setiap penyimpanan? Dalam kasus saya, saya benar-benar melakukan ini terhadap entitas kustom yang tidak memiliki pengindeksan apa pun - setidaknya untuk benchmark yang saya lakukan. Kami memiliki beberapa indeks khusus juga sehingga saya mungkin akan menggunakan tip ini!
kalenjordan

Saya tidak berpikir ada pengindeksan pelanggan tetapi pasti akan membantu Anda ketika memodifikasi banyak produk dan semacamnya. Apa pun itu patut dicoba!
Rick Kuipers

Maaf, ya data produk EAV dan semacamnya misalnya. Terima kasih.
kalenjordan

Hei! Anda mungkin harus (sebagian) mengindeks ulang setelah itu?
Alex

@Alex Ya, pengindeks akan diatur ulang ke MODE_REAL_TIME sehingga akan diindeks kembali sesuai jadwal. Anda dapat, tentu saja, memaksanya jika Anda mau.
Rick Kuipers
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.