Masa ke bait pertama drupal perlahan hosting

Saya meletakkan bersama-sama laman D7 dengan subtheme Minelli. Sepanjang perjalanan saya bereksperimen banyak dengan tema yang berbeza, modul yang berbeza. Di suatu tempat di sepanjang jalan saya menjadi isu prestasi ganjil, dan sekarang saya tidak benar-benar tahu apa tema / modul / config menyebabkannya.

Masalahnya ialah bahawa apabila saya mula-mula melawat laman web ini, ia mengambil masa kira-kira 15 saat sebelum rancangan halaman pertama. Saya kemudian boleh bergerak di sekitar tapak dan sangat responsif. Jika saya biarkan selama satu jam atau lebih, kemudian kembali kepadanya, permintaan pertama sekali lagi sangat perlahan.

Saya telah dibersihkan jadi cache ini yang tidak sepatutnya menjadi masalah. Juga, saya mempunyai tema yang kurang upaya dan modul yang saya tidak menggunakan. Saya berpindah tapak untuk infrastruktur baru tetapi masalah yang mengikutinya!

Di mana saya pergi selepas ini?

diminta 5 Jul '12 di 23:51

Saya telah mendapati hampir semua susunan (M / L / W) AMP dev, walaupun orang-orang khusus untuk Drupal seperti Bitnami, sedang teruk ditala atau tidak ditala pada semua (saya fikir dev timbunan Acquia adalah pengecualian). Dan sudah tentu lalai mySQL memasang untuk mesin pengeluaran tidak. InnoDB fail log adalah secara lalai seperti 5M dan memori yang diperuntukkan adalah miniscule. Sering penalaan yang betul adalah semua itu diperlukan untuk membuat solek tapak - walaupun hanya menjatuhkan di my-medium.cnf atau my-large.cnf adalah mencukupi. - Renee Ogos 7 '12 di 18:27

Terdapat begitu banyak jawapan yang baik untuk soalan ini, terima kasih kepada semua orang yang melihat komen ini dan menyumbang ke jawatan itu. Saya fikir jawapan ini tertentu merumuskan isu-isu utama yang bagus dan ringkas; check ini 3 mata teliti telah membantu mempercepatkan laman Drupal baik pada pelbagai mesin yang berbeza. Terima kasih @MPD - Clive ♦ Ogos 10 '12 di 00:32

Ivanhoe123 mungkin betul: Drupal 7 datang dengan 'mans cron miskin' didayakan secara lalai. Pendek kata, ia bermakna bahawa (sekali-sekala) cron dijalankan sebelum Drupal menjadikan halaman, melambatkan segala-galanya.

Sentiasa cuba untuk menggunakan kerja cron sebenar di tapak pengeluaran. Untuk maklumat lanjut teknikal melihat drupal.org/cron. atau bercakap dengan syarikat hosting anda.

Untuk melumpuhkan ia, pergi ke admin / config / system / cron dan pilih 'Jangan sekali-kali'.

Hanya dari rasa soalan ini, saya segera memikirkan tiga (3) perkara

• MySQL Storage Engine / CPU
• Pangkalan Caching
• Jadual Locking

Jika anda tidak menggunakan mana-mana teks penuh pencarian / pengindeksan, saya amat mengesyorkan anda menukar semua data MyISAM anda ke dalam SQL. MyISAM tidak direka untuk mengambil kesempatan daripada pelbagai CPU dan pelbagai teras. InnoDB sudah pun dikendalikan untuk pelbagai penggunaan CPU serta membaca / menulis HyperThreading.

Berikut adalah beberapa jawatan saya buat tentang perkara ini dalam DBA StackExchange dan dalam laman web ini berkenaan dengan penalaan MySQL untuk Prestasi InnoDB

Satu lagi hujah yang kuat untuk menukarkan semua data MyISAM untuk InnoDB adalah bagaimana MySQL cache data / indeks. The MyISAM Storage Engine hanya cache indeks. InnoDB cache data dan indeks. Sehubungan itu, anda boleh memperuntukkan memori yang cukup untuk InnoDB Buffer Pool untuk menampung salah satu yang berikut (yang mana lebih kecil)

• Semua InnoDB Data dan Indeks (Ideal jika anda mempunyai RAM yang cukup untuk itu dan juga untuk OS; menghapuskan kelewatan berikutnya)
• 75% daripada RAM dipasang (sekiranya anda mempunyai lebih banyak data SQL / indeks yang RAM; meminimumkan kelewatan)

Jika anda menggunakan MySQL 5.1, anda boleh menetapkan innodb_max_dirty_pages_pct = 0. Ini sedikit akan meningkatkan cakera I / O, tetapi InnoDB Buffer Pool akan dikosongkan cukup untuk membolehkan data lama dan halaman indeks untuk berputar tanpa cakera I / O mendadak. MySQL 5.5 dan MySQL 5.1 ini InnoDB Plugin tidak perlu pelarasan ini kerana ia mempunyai lalai yang lebih baik mekanisme curahan Buffer Pool.

Jika menggunakan InnoDB adalah keluar daripada soalan, anda mungkin perlu untuk pergi dengan memcached atau varnis. Ini membolehkan pemaju untuk menentukan bagaimana data lama cache akan tinggal di RAM pelayan. Sememangnya, ini akan memerlukan peningkatan pembangunan untuk membuat permohonan memcached / anda varnis-sedar.

Anda tidak boleh mengelakkan kelewatan awal selepas MySQL Mula semula. Namun, apabila anda meningkatkan MySQL menggunakan cadangan yang dinyatakan di atas / maklumat, anda tidak lagi mengalami kelewatan berikutnya.

Saya hampir jatuh Drupal untuk projek terakhir saya kerana ini.

Terdapat mesti saya lebih daripada satu sebab walaupun. Saya masih belum mencari penyelesaian 'menetapkan semua' yang berfungsi setiap kali isu ini gigil up.

Syslog dan Ubuntu / Debain

Kali pertama saya berlari merentasi sekejap 15 masa beban kedua adalah ketika menjalankan drupal pada (tidak dikongsi, Dedicated) Sistem Debian / Ubuntu berasaskan. Melumpuhkan modul Syslog adalah penyelesaian untuk saya.

Sebagai @BetaRide berkata, menggunakan xDebug atau beberapa profiler PHP lain adalah amat menyedarkan.

Masih Masalah - A Penyelesaian

Bagi pemasangan saya yang lain, saya masih rugi.

Isu ini lebih ketara pada pelayan pembangunan saya dan lalu lintas rendah saya Drupal memasang.

Sebagai penyelesaian saya telah setup kerja cron untuk memuatkan laman laman utama setiap 60 saat serta skrip cron Drupal ini setiap 300 saat. Ini jelas tidak optimum, tetapi saya lebih suka wget atau pengalaman curl 15 masa beban kedua bukannya pengunjung manusia.

Ramai orang mencadangkan isu ini boleh berkaitan dengan menyekat proses latar belakang segerak. terutamanya yang berkaitan dengan pekerjaan cron berat.

Jika benar, wujud satu sepasang besar modul di bawah pembangunan aktif oleh gielfeldt * yang mungkin mengurangkan isu ini buat keluar, atau sekurang-kurangnya, boleh menawarkan beberapa petunjuk dan pembina tapak bantuan mendiagnosis dan merawat penyebab tertentu dalam kes mereka. Kedua-dua menggantikan menyekat proses synchonous dengan bukan menyekat HTTP tak segerak atau arahan, dan kedua-duanya menawarkan laporan yang berkaitan yang boleh mengenal pasti proses menyusahkan:

• proses latar belakang dan modul yang dibundel membolehkan proses latar belakang Drupal yang beratur untuk diproses tak segerak, supaya mereka tidak menyekat. Ini dapat menghentikan masalah ini. Juga, dengan Proses Latar Belakang dibundel modul Apache Server dalam dev terkini, terdapat laporan UI asas tetapi memperbaiki dengan ciri-ciri untuk menyelia, membuka dan memeriksa masa mula dan kemajuan proses ini. Ini dapat mengenal pasti proses masalah tersebut.
• Ultimate Cron membina Proses Latar belakang untuk membolehkan tugas-tugas cron dicetuskan untuk mempunyai scehdules tak segerak berasingan mereka sendiri, setiap yang boleh dipantau dan berhenti di UI a. Serta menjadi hebat memisahkan tugas prestasi justeru menjejaskan tugas berat daripada biasa pembersihan rendah atas, ia juga memberikan anda laporan dengan maklumat yang sesuai yang disediakan seperti tempoh menjalankan setiap tugas cron dicetuskan individu, apabila mereka berjalan lalu, status semasa, dan lain-lain ini juga boleh mengeluarkan menyekat dari, dan / atau mengenal pasti, proses masalah.

Kedua-duanya adalah modul yang sangat berguna juga; bagi masalah ini, ia boleh digunakan untuk menguji (berbunyi sangat munasabah) teori bahawa tersumbat adalah disebabkan oleh proses menyekat segerak atau cron berjalan. Berpotensi, mereka boleh menyelesaikan masalah ini dengan menjalankan ini asynchronously bukan serentak, dan mereka juga berpotensi menawarkan petunjuk tentang mana proses khusus telah menyebabkan memegang ke atas. (Diberi amaran bahawa dokumentasi mereka adalah lebih kepada kerja dalam proses.

Jika, bagaimanapun, mereka tidak boleh dikonfigurasikan untuk membantu sama sekali, yang menunjukkan terdapat lebih kepada masalah ini daripada proses latar belakang hanya segerak. FWIW, saya tidak pernah mempunyai isu ini di laman web sejak mendapat modul ini untuk berfungsi dengan baik (lagi - sentuhan kayu) - tetapi saya telah melihat pada laman web saya sebelum ini, dan juga di laman-laman Drupal hidup di hutan.

Juga sedar modul plug-in lain yang berkaitan kini dalam pembangunan - cth di kompleks kes tinggi intensiti, Ultimate Cron Giliran Scaler. yang membolehkan pendikitan berdasarkan ambang-, mungkin membantu mengurangkan masalah berkaitan prestasi cron.

* Tiada gabungan, saya hanya seorang pengguna yang sangat kagum kerja mereka

menjawab Ogos 5 '12 di 20:20

Oleh kerana ini adalah memukul saya sekali lagi saya startet melakukan menyiasat masalah ini. Saya pasti boleh mengesahkan bahawa

1. panggilan kepada drupal_cron_run () dicetuskan oleh cron Poorman ini teras menambah

Ini bermakna bahawa menetapkan cron untuk tidak pernah dan menambah panggilan untuk cron melalui crontab menjadikan keadaan lebih baik. Memukul beberapa halaman sering digunakan kanan selepas itu untuk mengisi semula cache sekali lagi akan improove pengalaman pengguna.

Saya tidak pasti walaupun kira-kira caching. Saya tidak menyentuh tetapan cache lalai untuk laman web ini. Saya berfikir bahawa drupal adalah membina semula semua cache dari semasa ke semasa mungkin dicetuskan oleh cron, tetapi saya tidak pasti bagaimana ini dilakukan. Tetapi kelewatan 7s adalah cukup banyak apa yang saya lihat apabila saya tekan halaman selepas beberapa jam.

menjawab Ogos 6 '12 di 08:30

Isu-isu seperti ini boleh memandu anda kacang dan apabila saya telah berada dalam situasi yang sama membantu untuk mencari tahu apa yang menyebabkan isu itu akan satu langkah pada satu masa dan kemudian menguji dan tanpa nama dan log pengguna. (Kaedah lapisan bawang)

Anda menyebut anda mula perasan isu itu selepas bermain dengan beberapa tema dan adat pengekodan anda sendiri. Saya tidak tahu bagaimana kompleks adalah laman web anda dan tidak logik di sebalik itu, tetapi langkah-langkah berikut akan membantu anda mencari isu ini:

Dalam pelayan anda membuat folder atau akaun lain (ini mungkin lebih baik) di mana anda akan melakukan Drupal bersih memasang dengan versi yang sama anda gunakan pada laman web anda. Kemudian tanpa menambah mana-mana modul atau tema ujian masa yang diperlukan untuk laman web ini untuk bertindak balas permintaan pertama dan permintaan berikut. Jika semua kerja-kerja baik anda boleh mengabaikan isu-isu konfigurasi server, jika ia berkelakuan yang sama seperti semasa anda yang telah anda ralat konfigurasi sama ada dengan pelayan web anda atau pangkalan data.

Jika hasil dari langkah 1 yang baik dan pelayan bertindak balas segera dan permintaan di bawah adalah seperti cepat, kemudian memasang hanya tema dari tapak semasa anda ke dalam bersih memasang tapak dan menguji lagi. Jika segala-galanya masih bertindak pantas, maka tema anda tidak menjadi masalah dan anda perlu terus ke langkah 3 jika tidak, anda perlu bermula debugging tema anda * 1.

Jika selepas ujian ke atas langkah 2 tapak masih cepat mula membawa lebih modul di dalam laman web semasa anda dan pastikan untuk menguji masa tindak balas selepas menambah dan membolehkan setiap modul * 2.

Jika selepas menambah tema dan modul tapak masih bertindak balas permulaan pantas menambah konfigurasi, mencipta jenis kandungan, pandangan import, menu persediaan, dan lain-lain Jangan lupa untuk menguji tindak balas tapak selepas menambah setiap satu.

Persediaan dan konfigurasi bersedia dan tapak masih cepat, baik sekarang membawa data melalui. nod Import, segi taksonomi, komen, dan lain-lain saya tahu saya harus memperdengarkan bunyi seperti rekod pecah, tetapi sentiasa menguji selepas melengkapkan setiap langkah.

* 1 Testing tema: proses ini boleh mengelirukan dalam super yang dihuraikan tema, berikut adalah beberapa petunjuk:

Jika anda pautan kepada mana-mana js luar atau perpustakaan css, cuba menggunakan salinan tempatan yang sama.

Di dalam semakan fail template.php anda untuk fungsi itu mungkin mempunyai lebih panjang atau tidak berkesudahan gelung serta fungsi preprocess dan / atau cangkuk fungsi tema.

Semak fail template lain (page.tpl.php, dan lain-lain) dan mencari pemprosesan PHP mentah tatasusunan dan objek.

Jika menggunakan "Paparan" dan pemandangan fail template, kemudian semak kemudian juga.

Sentiasa semak laluan, mengoptimumkan imej, js dan fail css. Kadang-kadang fail js boleh mempunyai beberapa ketinggian berat apabila menggunakan pelbagai coretan kod dalam satu fail.

* 2 modul ujian: ujian modul adalah sedikit berbeza kerana penggunaan manipulasi berat dengan PHP dibenarkan. Berikut adalah beberapa petunjuk:

Komuniti modul disokong (CCK, Views, dan lain-lain) mempunyai isu-isu beratur di drupal.org memeriksa mereka untuk melihat jika terdapat apa-apa isu yang sedia ada tentang masalah anda dan jika ada kemungkinan bahawa mungkin terdapat patch untuk membaikinya.

adat sendiri modul dikodkan, juga jika anda dikodkan anda perlu menetapkan ia, betul. Semak coding anda dan menyemak penggunaan fungsi terhadap api.drupal.org, anda mungkin menggunakan fungsi Overkilling bukannya cangkuk.

Internet berkongsi modul kod adat, lakukan seperti dalam langkah 2, tetapi kali ini anda juga boleh menghubungi penulis modul asal dan biarkan dia / dia tahu tentang masalah ini.

Jika laman web anda adalah menaik taraf (D5 -> D6 -> D7) memeriksa penghijrahan atau menaik taraf skrip (biasanya dalam fail module.install) anda mungkin memerlukan "index" tambahan kepada konfigurasi jadual baru membuat perlahan SQL Pertanyaan X lebih cepat .

Jika anda rasa anda mempunyai visi terowong tentang masalah ini, melangkah keluar untuk sedikit dan melakukan aktiviti lain sepenuhnya un-berkaitan dan kemudian kembali kemudian untuk melihat semula isu itu.

Jika anda titik ping isu sebahagian daripada kod, tetapi tidak boleh membuat kepala atau ekor tentang bagaimana untuk memperbaikinya, cuba menjelaskan apa bahagian yang suppost lakukan untuk seseorang yang tidak mempunyai idea bagaimana untuk program atau bagaimana Drupal kerja dan menjadi bersedia untuk menjadi kejutan.

Nota: Jangan penggera jika selepas semula membina laman web anda semua mula bekerja seperti azimat yang merupakan salah satu ciri-ciri terbaik komputer mempunyai.

Seseorang menyebut bahawa GoDaddy akan menjadi perlahan. Banyak syarikat hosting berasaskan awan juga akan mempunyai kelewatan awal ini kerana perkhidmatan seperti AWS memilikinya. Ia lebih murah untuk mempunyai pelayan deprioritized secara automatik, dan orang-orang pelayan akan memerlukan kedua atau dua untuk 'bangun.'

Sebagai contoh, Pagodabox mempunyai 3-4 saat untuk bait pertama, sehingga pelayan adalah bahagia terjaga. Pagodabox telah sebenarnya menghasilkan wang menjaga pelayan terjaga, dan supaya anda boleh membayar tambahan untuk 'caffienate' laman web anda.

Juga, CDN boleh membantu anda. Anda sever web / db tidak akan sarat dengan berkhidmat halaman cache atau imej. A tutorial yang baik di sini: wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Dan. WebPageTest membuat saya gembira. www.webpagetest.org/ Bandingkan kali beban seluruh planet ini dan dengan pelayar web yang berbeza secara percuma. Gunakan ini untuk mendapatkan keputusan dunia sebenar untuk apa sahaja perubahan yang anda buat.

menjawab Ogos 7 '12 di 16:31

Ini adalah maklumat yang baik untuk mempunyai tetapi masalah masih berlaku di tapak pada mesin tempatan saya, memakan sumber-sumber tempatan sahaja - Clive ♦ 7 '12 Ogos di 16:36

masalah itu boleh menjadi mana-mana sahaja.

1. Pastikan anda tidak menghidupkan mod debug pada mana-mana tema atau modul. Sebagai contoh, dalam banyak tema terdapat pilihan untuk menjana semula pendaftaran tema.
2. Jika anda menjalankan pada dikongsi hosting seperti Godaddy, maka 15 sec untuk permintaan masa yang pertama adalah perkara biasa.
3. Menukar laman web anda atau halaman depan untuk pangkalan kod menggunakan modul Drush CTools Eksport. Ini akan menghapuskan apa-apa panggilan pangkalan data dan laman web anda akan dikendalikan sepenuhnya dari php.
4. Jika anda masih mendapat masalah, gunakan tetapan Devel dengan menghidupkan log Pertanyaan dan pemasa halaman pilihan di admin / config / pembangunan / devel. Lihat manakah di antara kedua mengambil masa yang lebih untuk menjana keseluruhan halaman.
5. Mulakan semula pelayan anda jika tiada kerja-kerja.
6. kes paling teruk memasang XHProf untuk melihat di mana mereka akan berdepan salah.

menjawab Ogos 4 '12 di 19:34

Jadi ini adalah bagaimana saya tetap masalah untuk memasang saya. Ia bukan satu penyelesaian sebenar kerana saya tidak boleh kuku sumber sebenar masalah (jika ada), tetapi ia adalah satu penyelesaian yang baik

1) CSS Agregat (tetapan cache). Ini mengurangkan kependaman separuh

2) Tetapkan cron untuk tidak pernah (dan menjalankannya secara luaran) - Nota: Saya telah "cuba untuk mula cron semasa ia sedang berjalan" kesilapan. Saya rasa ia telah cuba untuk memulakan cron di setiap pelancaran tetapi kerana ia gagal, page cron itu tidak menyebut cubaan terbaru, tetapi kejayaan yang terbaru.

3) Sediakan kerja cron yang menyeru halaman rumah dengan Lynx setiap 30 minit

Semua ini di server hosting yang dikongsi bersama. Ia tidak optimum tetapi ia berfungsi

Artikel berkaitan

Ada apa-apa isu yang diketahui dengan Drupal 7 tapak penghijrahan sedia ada ke dalam php 5.6? Untuk Drupal teras khusus, maklumat yang akan berada di barisan isu itu. Satu carian pantas untuk "5.6" membawa sehingga tidak ...

Nota: terima kasih khas tambahan untuk Doug Vann untuk memberikan motivasi untuk akhirnya hantar post blog ini! Pada awal 2016, apabila API Carian dan modul Solr berkaitan untuk Drupal 8 adalah pada awal alpha ...

Abdulrahman mengulas 18 Februari 2011 pada 19:23 (untuk mikeaja) Saya mempunyai dua nota di halaman: - Drupal 6 adalah kurang dari segi sumber yang diperlukan (terutamanya penggunaan cpu) daripada 7, yang menjadikan ia berguna yang ...

Anda boleh menambah pihak ketiga menyumbang modul untuk melanjutkan atau mengubah tingkah laku Drupal ini. arahan asas Dapatkan modul (s) sebagai arkib dan mengekstrak fail pemasangan Drupal anda ...

Drupal adalah Sistem Pengurusan Kandungan yang teguh yang berjalan pada pelayan LAMP. Pelayan LAMP menggunakan MySQL secara lalai, tetapi PostgreSQL juga boleh digunakan dengan Drupal. Ia boleh menjadi tuan rumah blog, forum, dan ...