Apa yang berkontribusi pada waktu eksekusi halaman drupal?

Saya memiliki situs yang saya selidiki yang memiliki masalah kinerja utama, menggunakan memcache saya dapat menurunkan jumlah kueri baik dalam jumlah dan waktu total pengerjaan (dari 3 detik hingga 230 ms) tetapi waktu eksekusi halaman sulit dihindarkan (saya melihat nilai-nilai yang dikeluarkan oleh devel) pengertian saya adalah bahwa waktu eksekusi halaman = waktu yang diperlukan untuk mengeksekusi php maka saya menginstal APC dan saya dapat melihat php opcode di-cache dan statistik menunjukkan hit di panel kontrol APC (apc.php dikirimkan bersama APC) tetapi waktu eksekusi halaman saya tidak turun. Jadi saya pikir pertanyaan saya ada dua:

Apa yang dikontribusikan semua untuk (lebih lambat) waktu eksekusi halaman? Apakah ini hanya waktu yang dibutuhkan untuk menjalankan php?
Pendekatan apa yang harus saya ambil untuk menurunkan waktu eksekusi halaman. Saya mencoba APC tetapi tidak banyak membantu

Jumlah modul PS yang digunakan di situs ini sangat besar (168) tetapi saat ini saya tidak dalam posisi untuk membuat rekomendasi itu, ini lebih seperti api dalam situasi lubang.

Sunting: Output menjalankan xhprof pada instance lokal (direkomendasikan oleh mikeytown), ini sepertinya gila Saya pikir hasil kemudian adalah karena meronta-ronta? menjalankan diff untuk url yang sama memiliki perbedaan drastis dan terlalu banyak penggunaan sumber daya. Juga tidak yakin mengapa ini menunjukkan nilai yang bukan dari hari ini: | (Saya baru saja menginstal xhprof di laptop ini)

Output menjalankan xhprof pada instance lokal

performance caching

— Dipen
sumber

Jawaban:

Dapatkan cachegrind dari situs Anda. Xdebug atau xhprof dapat menghasilkan satu. Ini akan memberi tahu Anda fungsi apa yang paling lama berjalan. Sampai Anda melakukan ini, ini adalah permainan menebak yang buruk.

— mikeytown2
sumber

Hai, terima kasih atas sarannya, saya baru saja menjalankan xhprof pada versi pengembangan lokal saya (laptop tidak di server) dan saya melihat ini - picasaweb.google.com/lh/photo/… Apakah ini nyata? Maksud saya, mungkinkah sebuah halaman menggunakan memori 750Mb?

— Dipen

Mungkinkah karena meronta-ronta? data yang kemudian diprofilkan untuk url yang sama, jika Anda melihat bagian bawah url yang sama membutuhkan sumber daya yang jauh lebih sedikit tetapi proses yang berbeda menunjukkan pemanfaatan sumber daya yang sepenuhnya berbeda dan ekstrem.

— Dipen

Ini benar-benar tergantung, tetapi untuk 99.9% pengaturan jika Anda menggunakan lebih dari 100MB ram ada sesuatu yang salah.

— mikeytown2

Selain jumlah modul, mungkinkah ada hal lain yang salah? Saya tidak yakin apakah modul dapat dihapus dari produksi segera. Btw, pada lokal saya menggunakan nginx + php-fpm dan pada produksi situs menggunakan lighspeed dengan cgi cepat.

— Dipen

Anda perlu menelusuri ke dalam cachegrind dan daftar fungsi apa yang menghabiskan seluruh waktu Anda. img715.imageshack.us/i/cgrindout.png

— mikeytown2

EDIT: Saya salah membaca posting asli. 168 modul banyak, dan 300 hingga 700 ms dari query SQL sangat besar . Semakin banyak modul yang akan Anda gunakan, semakin banyak permintaan mereka akan begitu modul melakukan beberapa.

Gunakan caching agresif selagi Anda bisa, cache semuanya, jika itu tidak cukup, coba cache proxy terbalik. Menggunakan CDN untuk file bisa sangat meningkatkan semuanya. Cache proksi terbalik juga dapat membantu Anda dengan menghapus beberapa cookie autentik ketika mengenai halaman yang tidak membutuhkannya (maka core akan berpikir pengguna adalah anonim bagi mereka dan memaksimalkan caching).

Dinamika inti Drupal membuat seluruh fajar melambat begitu Anda memiliki terlalu banyak modul yang berinteraksi pada saat yang sama.

Saya akan mengatakan, misalnya, jika Anda menggunakan banyak modul yang memuat data pada waktu hook_node_load () alih-alih menggunakan bidang, itu akan membuat banyak pertanyaan sementara penggunaan bidang akan memastikan efisiensi caching.

Rendering dapat mengambil banyak waktu juga, drupal_render () (API rendering kadang-kadang disebut) adalah bagian yang bagus dari API (sangat berguna) tetapi juga agak lambat. Beralih ke PDO (D7) dan DBTNG penuh (yang sangat bagus) juga menambah latensi yang tidak dapat diabaikan.

Yang mengatakan, inti dengan sendirinya cukup cepat (tetapi tidak terlalu banyak query SQL, bahkan dengan hampir tidak ada yang diinstal), modul kode yang buruk sering menjadi hambatan.

APC dapat membagi waktu eksekusi per 2 atau 3, tergantung pada kode yang berjalan. jika Anda mengonfigurasinya dengan baik (aktifkan semua optimasi APC, manual APC resmi ditulis dengan baik dan akan memandu Anda).

Jika Anda berada di kotak dengan sistem file lambat (sistem file jaringan atau hard drive lambat) itu dapat menyiratkan dampak yang terlihat pada waktu eksekusi. Drupal dibuat dari banyak file kecil, yang memaksa PHP untuk melakukan I / O di FS setiap kali memuat salah satu dari mereka (APC juga banyak membantu untuk itu).

DBMS yang salah konfigurasi juga bisa menjadi hambatan yang jelek, jika Anda menggunakan MySQL, pikirkan untuk melakukan fine tuning. Jika Anda menggunakan hosting bersama, jika itu bukan Drupal spesifik (atau siap), DBMS dan tumpukan PHP mungkin akan salah konfigurasi atau tidak disetel, yang dapat menyebabkan situs sangat lambat.

Jangan lupa untuk mengaktifkan semua cache. Jika situs Anda tidak diautentikasi berorientasi pengguna, maka aktifkan caching halaman agresif (itu benar-benar menakjubkan).

Semakin banyak Anda memiliki blok, semakin banyak halaman penuh akan lambat, blok modul Views akan menjadi hambatan subuh (tergantung pada plugin Views yang Anda gunakan, blok OG bisa sangat menyebalkan) jika Anda tidak membatasi visibilitasnya. berdasarkan per halaman, atau dengan kode PHP khusus (blok lain juga, selalu mengatur visibilitas blok Anda secara manual, sangat membantu kerangka kerja dengan menghindarinya untuk mencoba membuat blok kosong).

Hindari modul yang menggunakan hook_init (), hook_init () dijalankan di setiap halaman, bahkan jika Anda mendapatkan 403 atau 404, yang memperlambat segalanya (bahkan memperlambat waktu pembuatan gaya imagecache | style, dan 404 kesalahan pada file akan menjadi fajar lambat hanya untuk memberi tahu Anda file tidak ada).

— Pierre
sumber

Hai, di sini ketika saya mengatakan waktu eksekusi halaman yang saya maksud adalah nilai yang ditunjukkan oleh modul devel di bagian bawah halaman dan tidak menggunakannya dalam pengertian umum dari siklus permintaan / respons drupal yang juga mencakup pertanyaan SQL, dll. Pertanyaan saya adalah dalam konteks pengguna yang diautentikasi. Jadi ketika devel melaporkan waktu eksekusi halaman apakah itu juga termasuk query sql?

— Dipen

Saya tidak yakin apakah filesystem akan menjadi hambatan seperti saya pada 15k RPM filesystem linux. Permintaan SQL memakan waktu sekitar 300-700 ms tergantung pada halaman tetapi waktu eksekusi halaman ~ = 3 detik (dilaporkan oleh devel). Tidak yakin apa lagi yang bisa menjadi masalah.

— Dipen

Oh maaf, saya salah membaca posting asli Anda. Nilai devel dihitung dari boot ke shutdown (modul devel memiliki PHP sendiri shutdown handler untuk melakukan banyak hal termasuk ini). Saya tidak yakin persis kapan itu dimulai dan berhenti, tetapi cukup banyak seluruh waktu pembuatan Drupal dan spesifik bisnis termasuk dalam waktu eksekusi halaman itu. Ya, itu mencakup semuanya (termasuk waktu dan latensi SQL query), dan latensi sendiri (devel query logging juga memiliki dampak kinerja).

— Pierre