Strategi pembersihan cache yang hemat memori untuk situs besar?


30

Salah satu situs Drupal 7 saya memiliki ribuan bidang, banyak jenis konten, lebih dari 25 tampilan, dan ratusan (segera menjadi ribuan) jenis profil. Karena itu, saya menggunakan patch inti yang lebih baik untuk cache info bidang entitas (http://drupal.org/node/1040790), dan versi -dev Tampilan yang lebih baik cache tampilan dengan tampilan (daripada memiliki satu BESAR lihat baris cache dengan semua data tampilan di dalamnya).

Ini telah membantu sebagian besar halaman di situs untuk memuat dengan 20-30MB RAM yang digunakan, daripada 160MB + (bukannya menarik cache_ * baris tabel untuk bidang dan tampilan yang 10MB +, tambalan membantu menjaga data cache_ * jauh lebih efisien).

Ini menimbulkan masalah, bagaimanapun, dalam membangun kembali cache membutuhkan waktu yang sangat lama . Biasanya lebih dari satu atau dua menit. Dan selama ini, Drupal tidak akan memuat halaman apa pun (karena cache yang coba dibaca belum dibuat, permintaan lain harus menunggu).

Selama siklus lalu lintas rendah, ini bukan masalah besar; seratus atau lebih pengguna harus menunggu satu menit sebelum halaman dimuat. Tetapi selama siklus lalu lintas tinggi, server Apache mulai menjadi gila, dengan 40+ CPU load, dan memori dengan cepat terisi karena semua thread pekerja duduk menunggu, dan memaksimalkan memori mereka, menyebabkan pertukaran. Ini semacam spiral kematian. Restart dari httpd akan menghapus semuanya, tetapi butuh 5-10 menit agar semuanya kembali normal.

Tujuan saya adalah membuatnya jadi cache tidak membersihkan situs. Untuk satu, jika saya menggunakan fungsi pembersihan cache admin_menu individu (seperti "CSS dan JS", lalu "Menu", lalu "Theme registry", dll.), Semuanya berjalan lancar sampai saya menekan opsi "Page and else". Saat itulah cache pandangan diatur ulang (operasi yang sangat CPU dan basis data dengan jumlah tampilan yang perlu di-cache), dan ketika cache info bidang diatur ulang (yang juga CPU dan database-intensif di situs ini).

Jadi ... pertanyaan / ide saya:

  • Menggunakan drush dan / atau skrip shell lainnya, mungkinkah saya menghapus cache dengan cara yang lebih cerdas daripada "meledakkan semua cache sekaligus, dan berharap untuk membangun kembali yang bersih"?
  • Dapatkah saya memblokir permintaan http saat pembersihan cache sedang terjadi sehingga apache tidak tersumbat dengan banyak permintaan cache-cache?
  • Jika saya dapat menghapus cache di luar Drupal / permintaan httpd normal, saya mungkin dapat mengatur PHP memory_limit yang lebih tinggi untuk operasi cache yang jelas, dan membatalkan universal memory_limit saya (sekarang ditetapkan ke 256MB, kalau-kalau ada thread httpd individu perlu menghapus cache. ...).

Pada dasarnya: Apakah ada cara cerdas dan anggun untuk menghapus semua cache dengan Drupal selain hanya mengklik tombol di UI, atau menggunakan drush cc all?

[ Edit untuk klarifikasi : Masalah utama yang saya miliki adalah membangun kembali cache , yang (a) perlu waktu, dan (b) memblokir semua permintaan lain sampai pembangunan kembali selesai. Saya ingin menemukan cara untuk membuatnya sehingga pembangunan kembali tidak begitu mematikan selama masa lalu lintas tinggi.]


2
Pertanyaan menarik. Jika Anda menonaktifkan caching, apakah kinerja situs Anda memadai? TKI, sudahkah Anda mengoptimalkan Apache / PHP / MySQL untuk dijalankan juga tanpa mengaktifkan caching? Jelas, saya belum melihat sistem Anda, tetapi pengaturan apc.stat = 0 dan memastikan Anda memiliki cukup memori untuk APC akan membantu mengurangi penggunaan disk. Menggunakan mysqltuner.pl juga akan memberi Anda indikasi apakah MySQL adalah hambatannya. Kemudian Anda dapat mengaktifkan caching dan tweak (ini akan meningkatkan penggunaan DB, jadi Anda mungkin perlu menyesuaikan parameter MySQL).
mpdonadio

Saya menggunakan Redis (mirip dengan memcache) untuk menjaga tabel cache view dalam memori. Itu meningkatkan waktu muat secara drastis. Melihat ke depan untuk memiliki fitur "views cache by display" dalam rilis yang stabil, itu masuk akal.
uwe

@MPD - Menonaktifkan caching akan dengan cepat membunuh seluruh situs; biasanya 100-500 pengguna terautentikasi, dan beberapa bagian situs cukup berat. Masalah terbesar bagi saya adalah tidak membaca cache (saya telah bereksperimen dengan cache pengguna Memcached, Redis, dan APC), tetapi dengan cache yang dibangun kembali, yang sangat intensif CPU.
geerlingguy

Idealnya Anda ingin menggunakan data cache lama saat cache baru sedang dibangun kembali. Apakah ini benar?
mikeytown2

@ mikeytown2 - benar — itu ideal.
geerlingguy

Jawaban:


9

Apakah ada cara cerdas dan anggun untuk menghapus semua cache dengan Drupal selain hanya mengklik tombol di UI, atau menggunakan cc drush semua?

The tindakan Cache modul melakukan itu. Itu tergantung aturan. Sebagai contoh, Anda dapat mengatur aturan untuk menghapus tampilan tertentu ketika sebuah simpul tipe "x" telah ditambahkan atau diperbarui. Periksa dokumen untuk detail lebih lanjut.

Lihat juga modul cache yang anggun - belum mencobanya tetapi terlihat menarik.


Saya sudah menggunakan drush cc [type]untuk membersihkan cache spesifik (mirip dengan tindakan cache), tapi saya lebih tertarik menemukan cara untuk membersihkan cache lebih anggun dan memastikan utas httpd lainnya tidak membunuh server Apache.
geerlingguy

1
Sepertinya drush cc akan menghapus semua cache view. Dengan tindakan cache Anda bisa menghapus tampilan atau tampilan tertentu. Mungkin ada bug dalam versi dev, jika tidak maka tidak akan butuh satu atau dua menit untuk membangun kembali cache. Apakah Anda memiliki masalah yang sama menggunakan tampilan 7.x-3.5? Lihat juga drupal.org/project/cache_graceful - belum mencobanya tetapi terlihat menarik
uwe

Tampilan dev memecah tampilan yang ditampilkan ke dalam baris cache mereka sendiri, untuk membantu kinerja cache membaca Ini berarti bahwa pandangan menghabiskan mungkin 5x lebih banyak waktu membangun cache (tapi itu membantu mengurangi penggunaan memori saat membaca cache sangat banyak!).
geerlingguy

Bisakah Anda menambahkan informasi tentang Cache Graceful ke dalam jawaban awal Anda? Saya akan menerimanya, karena modul itu sedikit membantu (tetapi tidak memperbaiki masalah sepenuhnya untuk saya). Saya pikir saya harus melakukan sedikit penyusunan ulang situs untuk menggunakan lebih sedikit bidang dan jenis entitas untuk benar-benar memperbaiki masalah saya.
geerlingguy

baik. Saya akan tertarik untuk mendengar tentang pengalaman Anda dengan cache_graceful. Bagian mana yang tidak diperbaiki?
uwe

2

Masalah utama adalah bahwa Anda menggunakan MySQL untuk menyimpan data cache - untuk situs beban tinggi ini adalah solusi yang sangat tidak efektif.

Saya menyarankan untuk menggunakan Memcache sebagai gantinya. Ini secara dramatis akan meningkatkan kinerja sistem cache dan memberi Anda 2 manfaat besar:

  1. Memcache jauh lebih cepat untuk operasi baca dan tulis sehingga MySQL - semua operasi yang Anda cache (dan cache penuh dibangun kembali) akan bekerja lebih cepat.
  2. Karena data cache tidak disimpan dalam DB lagi - membersihkan cache tidak akan memblokir permintaan MySQL lainnya.

Berikut adalah contoh konfigurasi Memcache untuk Drupal 7.


Saya telah menggunakan memcached dan APC keduanya, dalam berbagai cara, dan sementara mereka sangat membantu dengan membaca cache, masalah utama yang saya miliki adalah pembangunan kembali yang sebenarnya; database hampir tidak melakukan apa-apa saat server web sedang melakukan cache cache selama proses pembangunan kembali (sangat lambat / lama).
geerlingguy

APC dan Memcached membuat hal yang berbeda. Saya pikir konfigurasi Memcached yang benar akan membantu Anda. BTW, jika situs Anda banyak dikunjungi oleh pengguna anonim - Anda dapat menggunakan Varnish. Dalam hal ini Varnish akan menggunakan sistem cache sendiri dan Apache tidak akan dieksekusi untuk permintaan anonim.
Eugene Fidelin

Situs ini memiliki hampir 100% lalu lintas yang diautentikasi, jika tidak saya akan mempertimbangkan menggunakan Varnish. Saya mungkin melihat ke dalam modul Cache Graceful pada saat ini.
geerlingguy

0

Menggunakan drush dan / atau skrip shell lainnya, mungkinkah saya menghapus cache dengan cara yang lebih cerdas daripada "meledakkan semua cache sekaligus, dan berharap untuk membangun kembali yang bersih"?

Jika Anda tidak ingin drush cc type_of_cachemenghapus semua cache, gunakan: untuk menghapus yang spesifik, atau tentukan sendiri.

Atau hapus semua tabel seperti cache secara manual, mis

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v 

Jika Anda menggunakan memcached (Bash syntax), coba:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Dapatkah saya memblokir permintaan http saat pembersihan cache sedang terjadi sehingga apache tidak tersumbat dengan banyak permintaan cache-cache?

Aktifkan mode pemeliharaan ( drush -y vset maintenance_mode 1) untuk mencegah orang mengakses situs. Atau konfigurasikan front-end untuk mengarahkan ulang di tempat lain (mis. Dalam Varnish, redirect di Apache, atau ubah .htaccess).

Jika saya bisa menghapus cache di luar Drupal / permintaan httpd normal, saya mungkin bisa mengatur PHP yang lebih tinggi memory_limituntuk operasi cache yang bersih, dan mundur universal saya memory_limit(sekarang ditetapkan ke 256MB, kalau-kalau setiap thread httpd individu perlu menghapus cache .. .).

Mengosongkan cache tidak membutuhkan lebih banyak memori, tetapi membangun kembali cache setelah dihapus akan membutuhkan lebih banyak. Anda selalu dapat menghangatkan cache dengan menjalankan cron atau membuka halaman apa pun, misalnya

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

Tentukan -nuntuk mengabaikan php.inipemrosesan yang juga dapat mempercepat proses pembersihan cache.


-1

Ada potensi biaya moneter yang terlibat, tetapi Anda bisa menggunakan pengaturan server caching seperti Varnish. Sisi baiknya adalah bahwa Varnish akan melayani situs Anda saat cache Anda dihapus pada server produksi, tanpa pengguna menjadi lebih bijak.

The downside: tergantung pada berapa detik / menit downtime dari server produksi vs pengaturan batas waktu VCL Anda, Varnish dapat memperbarui selama waktu itu dan Anda akan melihat layar kesalahan Varnish 503.

Tetapi pendekatan ini bersama dengan Redis atau Memcache dapat membantu.


Pertanyaan ini hanya berkaitan dengan cache Drupal internal; pembangunan kembali cache Drupal memakan waktu lama, dan lapisan cache tambahan di luar / di depan Drupal tidak akan banyak membantu untuk membangun kembali data cache yang sebenarnya (selain membongkar beberapa lalu lintas yang seharusnya ditahan oleh server web untuk sementara sementara cache dibangun kembali).
geerlingguy

Dalam hal ini, saya menemukan Zend OpCache berfungsi dengan baik. :-)
mulderjoe
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.