Refactoring Wordpress untuk meningkatkan kinerja memori [tertutup]

Saya melihat dari dekat pada konsumsi memori Wordpress. Di situs saya, tampaknya setiap halaman mencapai 20MB RAM dialokasikan, hanya untuk mempersiapkan lingkungan yang nyaman untuk semua plugin untuk dijalankan. Saya merencanakannya sebagai berikut:

Tidak ada satu pun tempat untuk dioptimalkan, tidak ada satu pun orang jahat yang makan sebagian besar memori. Konsumsi semua tersebar di banyak banyak modul php.

Bagaimana kita bisa membuat Wordpress menginisialisasi lingkungannya dalam memori hanya sekali, dan kemudian menggunakannya kembali berkali-kali untuk setiap klik? Saya tidak ingin PHP lambat memakan 20 MB di setiap klik pengguna - bahkan pada server dengan banyak memori, perlu beberapa detik untuk menyelesaikan semua pekerjaan. Pada dasarnya Anda membutuhkan potongan memori hanya baca yang dapat digunakan kembali.

Juga ... mengapa 20MB? Adakah yang bisa memberikan wawasan tentang ini?

Sunting: Ini adalah output WinCacheGrind di Wordpress yang berjalan di mesin pengembangan saya (jauh lebih cepat dari shared hosting). Seperti yang Anda lihat, dibutuhkan lebih dari sedetik untuk menghasilkan HTML halaman utama. Lambatkan itu dengan shared hosting dan Anda memiliki resep untuk masalah. Saya memilih metode yang menghabiskan sebagian besar waktu. Bagaimana cara Anda mengoptimalkan ini?

Sunting: Berikut ini adalah statistik kueri dari alat profil.fp yang fantastis ini .

Muat: 12 kueri - 532ms - 19.1MB - 43 hit cache / 53
Permintaan: 15 pertanyaan - 563ms - 19.0MB - 72 hit cache / 86
Tampilan: 21 kueri - 705ms - 19.2MB - 234 hit cache / 257

Sunting: Apakah Anda ingin melihat sesuatu yang dijamin membuat Anda takut? Masukkan baris ini di akhir index.php:

echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

Saya mencoba menghitung berapa kali isi postingan saat ini disimpan dalam memori. Saya menghitung 20 contoh. Kemudian saya menyadari bahwa PHP memiliki penghitungan referensi, sehingga jumlah salinan dikurangi menjadi hanya tiga: dua tampaknya dalam WP_Query, satu di cache objek. Saya sedang menyelidiki lebih lanjut.

Inilah mengapa saya pikir WordPress perlu refactoring menargetkan masalah memori. Anda tidak dapat lagi menyalahkan konsumsi memorinya pada kerumitan semata dari apa yang dilakukannya. Itu hanya melakukan banyak hal yang salah .

Sunting: Setelah seharian mencoba mencari tahu ini, berikut adalah temuan saya:

1) 88% dari semua memori berasal dari permintaan atau sertakan atau sertakan jenis panggilan:

2) File php termasuk sebagian besar terjadi selama bagian pertama melayani permintaan (tidak mengherankan), yang juga merupakan tempat semua memori habis:

3) Cukup menarik untuk memplot semua fungsi yang sedang dieksekusi saat membuat permintaan. Ada total lebih dari 12000 panggilan. Saya gugup agar lebih terlihat (sumbu Level pada dasarnya adalah kedalaman tumpukan):

4) Satu-satunya cara maju yang dapat saya pikirkan adalah meminimalkan jumlah file .php yang disertakan. Jika saya membagi fungsi per file asalnya, Anda dapat melihat bahwa banyak file paling banyak dipukul sekali atau dua kali. Kita perlu cara bagaimana melompati mereka ketika mereka tidak diperlukan. Misalnya plugin cadangan basis data jauh saya dimuat dan terdaftar, hanya untuk tidak pernah digunakan sama sekali. Berikut adalah plot di atas dengan nama file:

Saya menawarkan hadiah yang layak untuk semua reputasi saya :) untuk refactor yang akan menyebabkan pemotongan jejak memori blog saya hingga 30% atau lebih.

Sunting: Saya menginstal WP 3.1, ini adalah perbandingan dengan versi yang lama.

Biru adalah WP 3.1, merah adalah 3.0.4. WP baru lebih cepat, tetapi juga memakan lebih banyak memori.

Berikut adalah daftar dengan memasukkan file.

Ini biarkan saya menyadari betapa banyak memori yang dimakan oleh "paket SEO All In One" - satu jalan adalah dengan menggunakan hanya sebagian kecil dari fungsi plugin untuk mendapatkan apa yang saya inginkan. Juga, plugin saya sendiri sepertinya sangat buruk.

Saya ingin mencoba memuat bersyarat pada misal comment.php (saya melarang komentar di blog saya) dan beberapa lainnya. Saya menghapus semua kode yang sudah usang. Saya memangkas kses.php untuk hanya memuat tabel globalnya sesuai permintaan. Saya menyederhanakan l10n (saya tidak melakukan pelokalan), membuat fungsinya mengembalikan string segera, tanpa pencarian. Saya masih jauh dari angka 30% yang saya set up secara sewenang-wenang.

Sunting: Saya mengunduh dan mengaktifkan APC dengan pengaturan default (32MB cache opcode). Berikut ini perbandingannya:

Anda dapat melihat bahwa pemuatan kode dipercepat secara besar-besaran, dan kode juga membutuhkan lebih sedikit ruang dalam memori (mungkin karena kita hanya berurusan dengan opcodes, bukan sumber aslinya). Namun konsumsi memori masih cukup tinggi.

Tidak sepadan dengan masalahnya. WordPress tidak memakan banyak memori hanya karena. Ini memakan banyak memori karena menjalankan banyak fungsi di bawah tenda.

Jauh lebih mudah dan efisien untuk men-cache hasil (halaman dihasilkan) dengan plugin cache statis dan sajikan. Dengan begitu sebagian besar pengunjung bahkan tidak akan menekan WP itu sendiri.

Dan inilah mengapa saya pikir WordPress sangat membutuhkan penulisan ulang. Anda tidak dapat lagi menyalahkan konsumsi memorinya pada kerumitan semata dari apa yang dilakukannya. Itu hanya melakukan kesalahan.

Kesimpulan yang naif. Baca Hal Anda Tidak Harus Lakukan, Bagian I .

Terima kasih untuk plot penggunaan memori.

Sunting jauh kemudian: Autommatic telah merilis perpustakaan bernama prefork yang tampaknya melakukan apa yang Anda minta: memuat kode WordPress dalam RAM hanya sekali.

Dimulai dengan WordPress 3.2, PHP 5.2 akan menjadi persyaratan minimum. Saya pikir dengan itu di bawah ikat pinggang kami, bit inti dapat mulai direstrukturisasi, dan menggunakan kelas dengan memuat otomatis. Ini akan memungkinkan kita menghindari memuat beberapa potongan kode kecuali mereka benar - benar diperlukan. Misalnya, jika tidak ada embed atau galeri dalam tampilan halaman, kami mungkin dapat menghindari memuat banyak kode media.

Namun, bahkan jika mereka memutuskan untuk menempuh rute itu, saya akan berharap itu menjadi evolusi yang lambat (seperti banyak perubahan lain yang terjadi). Ini akan memerlukan pengocokan lokasi banyak file dan kode, yang mungkin dapat merusak kompatibilitas untuk beberapa plugin.

Bagian dari masalah (jika memang bisa disebut itu) adalah bahwa tanpa pemuatan bersyarat semacam itu, kerangka inti tidak dapat mengetahui sebelumnya tentang fungsi mana yang akan dibutuhkan atau tidak perlu untuk menghasilkan tampilan konten. Jadi banyak fungsi yang harus dimuat kalau -kalau dibutuhkan.

Bagaimana kita bisa membuat Wordpress menginisialisasi lingkungannya dalam memori hanya sekali, dan kemudian menggunakannya kembali berkali-kali untuk setiap klik?

Ini disebut opcode-caching.

http://en.wikipedia.org/wiki/PHP_accelerator

Anda mungkin tidak akan berhasil mengurangi penggunaan ram sebanyak itu. Tetapi jika Anda menggunakan mod_php, Anda mungkin ingin beralih ke mod_fcgidgantinya.

sementara mod_php sedikit lebih lambat, ia memuat php bahkan ketika itu tidak perlu, seperti melayani gambar, file statis, atau bahkan caching. Jika Anda memiliki banyak permintaan, ini banyak ram.

menggunakan fcgid akan mengurangi ini banyak.

juga, menggunakan cache statis (seperti cache w3total) akan menghindari memanggil php sama sekali yang merupakan keuntungan yang sangat besar: penggunaan ram lebih sedikit, koneksi db lebih sedikit.

Ha. Saya sedang mengerjakan aplikasi web sekarang karena saya sepenuhnya bermaksud untuk membebani data dan penggunaan melebihi apa yang bisa ditangani oleh akun hosting bersama saya, jadi saya memutuskan - walaupun akan sangat mudah dibuat di WP - untuk mencoba bekerja dari BackPress sebagai kerangka kerja dan membangun hanya apa yang saya butuhkan untuk kasus penggunaan khusus saya.

Jadi saya sudah bisa mengurangi lingkungan inti saya dari ratusan file PHP di WP menjadi hanya dua puluh atau lebih yang sebenarnya saya butuhkan, sementara masih bisa memanfaatkan semua db, HTTP, manajemen pengguna, format, dan cron fungsi yang saya sukai di WordPress.

Masalahnya adalah itu banyak pekerjaan, dan saya tidak akan pernah mempercayai hackjob saya untuk apa pun di luar penggunaan pribadi saya. Jika Anda ingin menggunakan lingkungan WP lengkap, ambil apa adanya. Sebagus itu karena ratusan pengembang menyelaraskannya selama beberapa tahun. Seperti semua orang di sini mengatakan, Anda akan mendapatkan lebih jauh dengan menemukan rencana hosting yang lebih baik dan meneliti teknik caching daripada yang mungkin Anda dapatkan dengan meretas inti.

Ya, WordPress memuat semuanya terlebih dahulu dan kemudian melakukan apa yang kami minta. Saya dapat mengingat di suatu tempat bahwa kita dapat membuat kumpulan virtual dalam RAM tempat kita dapat meletakkan file. Saya memiliki ide untuk menempatkan seluruh WordPress dalam memori (<10MB) & kemudian kita dapat menghemat banyak I / O yang mana saja seharusnya memberikan peningkatan kecepatan. Tetapi saya tidak pernah mendapat kesempatan untuk mencobanya dan terlebih lagi saya tidak begitu mahir dalam mengejar sesuatu seperti itu. Tapi sepertinya patut dicoba.

beberapa saran dasar:

1. plugin cache total w3 untuk cache ..
2. dapatkan memcache terinstal dan diaktifkan, juga aktifkan dari pengaturan cache total w3 (cache opcode adalah pilihan yang bagus juga tetapi itu tidak berjalan baik dengan plugin cache total w3)
3. perkecil kueri untuk mengarahkan tautan dalam file tema ..
4. Nonaktifkan semua plugin tambahan yang tidak digunakan dan hapus.
5. mengoptimalkan Database.

saya menjalankan situs wordpress terkenal dengan lalu lintas yang besar setiap hari .. saya bahkan tidak pada dedicated, melakukan yang besar untuk saya :)