hip hop vm drupal hosting

Mac lalu, Facebook mengumumkan HACK, sumber terbuka bahasa pengaturcaraan baru untuk HipHop Mesin Virtual (HHVM) disebut-sebut untuk saling beroperasi dengan lancar dengan PHP. Berikutan pengumuman itu, saya terpesona menonton segala apa yang mereka cuba dengan keluaran baru dalam usaha untuk perah prestasi sebanyak mungkin dari PHP. Ini memberikan saya idea: Walaupun kami tidak menghadapi cabaran yang tepat bahawa Facebook tidak setiap hari, ia akan menjadi menarik untuk melihat apa yang akan berlaku jika saya cuba berjalan Drupal bawah HHVM, lelaran terbaru enjin pelaksanaan Facebook.

pakej rasmi HHVM hanya diedarkan untuk Ubuntu dan Debian, tetapi bersyukur kerana sesetengah orang yang berdaya usaha telah dibungkus mereka untuk CentOS. Jadi dengan pendirian yang cepat daripada Mesin Maya dan beberapa pakej tambahan, kami baik untuk pergi. Untuk menguji, kami memilih tapak yang agak kompleks yang kita maju tahun lepas, yang dibina di atas Panel biasa dan Paparan Suite dengan hubungan yang signifikan di antara kandungan. Ini bermakna bahawa pada halaman tertentu, Drupal adalah mungkin untuk memuatkan dan menyebabkan beberapa entiti di luar hanya satu di halaman.

Saya mengambil PHP semasa dan pangkalan data untuk laman web ini dan berdiri ia sehingga pada VM tempatan dengan 4 teras dan 6.5 GB memori. Kami telah mendapatkan pengoptimuman kecil FPM untuk menetapkan bilangan pelayan, bersama-sama dengan beberapa kenaikan kepada cache dalam MySQL. Selain daripada itu, ia cukup banyak pemasangan vanila sebanyak PHP 5.3 dengan XCache, Percona 5.5, dan nginx. Matlamatnya adalah untuk menyediakan sebanyak daripada "epal dengan epal" perbandingan kedua-dua jurubahasa tanpa sebanyak kira untuk membuat segala-galanya secepat mungkin. Kami kemudian spidered tapak dan sampel daripada 1000 URL secara rawak dan berlari JMeter menjana 30 permintaan serentak terhadap laman berjalan dengan HHVM dan PHP-FPM. Kami mencatatkan masa dan beban pada pelayan.

Bermula, kami berlari ujian terhadap permulaan sejuk laman web ini. Kita mengosongkan cache Drupal dan dimulakan semula nginx, PHP-FPM dan MySQL. Kami kemudian memukul halaman rumah dengan satu permintaan untuk membina item berterusan cache. Sebagaimana yang diminta mula ramping, masa untuk menyelesaikan setiap satu naik seperti yang diharapkan.

Purata masa tindak balas sampel setiap 5 saat, permulaan sejuk

Apa yang berlaku pada pelayan cermin itu.

CPU keseluruhan dan penggunaan memori, permulaan sejuk

Kami memeriksa proses sebenar yang menjana CPU dan memori yang penggunaan, dalam kes ini hanya menarik keluar mysqld sejak menjejaki setiap proses dari PHP-FHM adalah mencabar.

penggunaan CPU untuk mysqld, mula sejuk penggunaan memori untuk mysqld, permulaan sejuk

MySQL telah menggunakan mana-mana sahaja 40-60%, dengan pancang Beberapa hanya lebih 100% daripada satu teras. Semua teras yang lain sama sekali digunakan oleh PHP-FPM. Begitu juga, MySQL telah menggunakan, secara purata, kira-kira 300 MB memori. Saya tidak sepenuhnya pasti apa yang menyebabkan kawasan di mana menjeda pemprosesan dan masa tindak balas naik mendadak. Saya melihat mereka pada semua senario, dan tekaan saya adalah bahawa mereka adalah disebabkan oleh beberapa jenis I / O menyekat, mungkin dari MySQL atau nginx.

Sebagai ujian kedua, kami berlari URL sama yang tepat terhadap sistem, mengosongkan cache Drupal untuk melihat jika membakar dalam lelaran untuk XCache dan MySQL akan membantu. Secara keseluruhan, ia mengurangkan masa tindak balas median oleh keseluruhan 400 milisaat dan menambah pengeluaran dengan kekalahan 2,081 muka surat setiap minit. Masa respons secara umumnya lebih sedikit bergelora dengan lebih sedikit daripada puncak dan lembah dari jangka masa sebelumnya, tetapi hasilnya cukup konsisten.

Purata masa tindak balas sampel setiap 5 saat, mula hangat CPU keseluruhan dan penggunaan memori, mula hangat

Selepas itu, kita semula mesin, beralih daripada PHP-FPM untuk HHVM. Syukurlah, ia menyokong FastCGI, jadi ia adalah satu perkara yang mudah mengubah konfigurasi nginx sedikit. persediaan adalah sama benar untuk PHP-FPM; kami memastikan bahawa cache Drupal telah dibersihkan dan dimulakan semula MySQL dan nginx. Kami kemudian memukul laman web dengan satu permintaan dan mula sehingga JMeter.

Purata masa tindak balas sampel setiap 5 saat, permulaan sejuk

Perkara pertama yang kita perhatikan adalah bahawa ia disiapkan pada hanya di bawah separuh masa, 06:28 berbanding 13:21. Setiap bahagian graf sambutan yang lebih baik, dan kedua-dua puncak dan lembah adalah jauh lebih rendah. The gangguan kecil di awal lagi sebelum ia jatuh, adalah JIT pengkompil berjalan.

Melihat kepada statistik pelayan, mereka telah bertambah baik juga.

CPU keseluruhan dan penggunaan memori, permulaan sejuk

HHVM berjalan sebagai proses tunggal, supaya kita dapat menangkap CPU dan memori penggunaan secara berasingan untuk mereka.

penggunaan CPU untuk mysqld dan hhvm, sejuk penggunaan permulaan Memori secara mysqld dan hhvm, permulaan sejuk

Hanya melihat graf ini, ia agak mudah untuk memberitahu beberapa perkara. Iaitu, kedua-dua CPU dan memori penggunaan untuk HHVM diperbaiki lebih PHP-FPM. penggunaan memori puncak bagi HHVM hanya kira-kira 320 MB untuk jumlah penggunaan sistem kira-kira 20% berbanding dengan 25 - 26% di bawah PHP-FPM. Begitu juga, jumlah penggunaan CPU adalah lebih rendah dengan hanya beberapa pancang kepada lebih 90% dan median lebih dekat dengan 60%, berbanding dengan kenaikan konsisten 95% CPU dan median lebih dekat kepada 70 - 75%.

Sama dengan ujian PHP-FPM, kita juga berlari senario terhadap permulaan yang hangat HHVM. Seperti PHP-FPM, terdapat perbezaan yang sangat sedikit, hanya kira-kira perbezaan 200 milisaat dalam masa tindak balas median.

Jika kita ingin melihat tahap yang tinggi, HHVM membandingkan dengan baik untuk PHP-FPM.

Kami melihat lebih dua kali ganda daya pemprosesan dan kurang daripada separuh masa tindak balas purata. Digabungkan dengan penurunan dalam sumber-sumber sistem yang diperlukan, ia adalah satu hujah cukup menarik untuk beralih kepada HHVM.

Terdapat beberapa pertimbangan, namun. Yang paling besar adalah bahawa manakala pasukan HHVM itu cuba untuk mendapatkan dekat dengan Zend PHP mungkin, mereka tidak ada lagi. Sehingga laporan terkini, HHVM pas 99,83% daripada ujian unit untuk Drupal, tetapi tidak ada idea bagaimana apa idiosinkrasi wujud dalam pelbagai modul menyumbang akan mempengaruhinya. Sebagai contoh, kita tidak boleh mendapatkan GD untuk bekerja pada semua, walaupun semua tanda-tanda yang sepatutnya. Syukurlah, ia mudah diganti dengan ImageMagick - bagi kebanyakan manipulasi. Malah, kita tidak berjalan ke dalam mana-mana halaman semasa ujian kami yang gagal dengan HHVM, tetapi anda tidak tahu apa yang mungkin tidak berfungsi sehingga anda benar-benar menjalankan ke dalamnya. Di samping itu, ujian itu dilakukan sepenuhnya pada bahagian hadapan. Walaupun kami telah melalui beberapa senario umum kepada soal pentadbiran, kami tidak menguji yang teliti. Beberapa modul PHP telah dialihkan, seperti APC dan memcache, dan ada kerja oleh pihak ketiga untuk menambah orang lain, seperti MongoDB, Ice dan Redis, tetapi banyak modul yang belum dan mungkin tidak akan.

Ia juga merupakan sasaran yang bergerak. Sekarang pasukan HHVM itu sedang mengkaji sekitar kitaran pelepasan 8 minggu. Mungkin, tidak akan ada terurus penting kerana mereka bergerak ke hadapan, tetapi anda tidak tahu. Begitu juga, mereka menyasarkan Ubuntu dan Debian untuk pakej rasmi, jadi jika anda menjalankan Fedora atau CentOS anda perlu sama ada membina dari sumber atau bergantung kepada repositori pihak ketiga yang mungkin tidak up to date.

penafian

Keputusan prestasi yang ditunjukkan di atas adalah dari menjalankan tapak pengeluaran pada banyak 'bukan pengeluaran' mesin maya berjalan pada MacBook Pro dengan pemproses i7 Core 2.3 GHz. Terdapat sangat sedikit penalaan pada mana-mana bahagian timbunan untuk memastikan prestasi yang terbaik. ujian beban dilakukan dari mesin yang berasingan melalui rangkaian wayarles, walaupun satu yang tidak digunakan untuk sebarang tujuan lain. Ujian beban tidak mengandungi sebarang masa menunggu atau permintaan untuk aset bukan PHP dan tidak bertujuan untuk mensimulasikan penggunaan sebenar, semata-mata untuk penanda aras prestasi jurubahasa PHP.

Artikel berkaitan

Memilih Drupal hosting boleh menjadi satu tugas yang mudah jika anda tidak pasti apa yang disediakan untuk anda. Dalam beberapa kes, anda mungkin baik dengan sesuatu seperti persekitaran hosting yang dikongsi bersama yang Hostgator atau ...

Dicatat oleh juliejohnson26 pada 3 Februari, 2010 at 22:38 Semakin saya belajar tentang Drupal, semakin saya menyedari bahawa saya perlu belajar beberapa PHP. Adakah sesiapa yang mempunyai cadangan tentang di mana untuk berbuat demikian? Adakah ...

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 ...

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 ...

Saya telah menggunakan web beberapa 2 platform sehingga sekarang, seperti blogger, wordpress.com. weebly dan beberapa laman web blog yang lebih, jadi saya boleh katakan saya adalah seorang "berpengalaman" blogger (yang bermaksud bahawa saya tahu bagaimana untuk menggunakan ...