Therefore if I can prove that there's no particular difference to testing with certain concurrency levels, I typically move the benchmark to a level that mirrors traffic patterns I actually see on my sites :)Ībsolute numbers mean nothing to me-it's the comparison between test A and test B, and how reproducible that comparison is, that matters. In all my benchmarking, I care more about deltas and reproducibility than measuring raw, clean-room-scenario performance, because unless a result is absolutely reproducible, it's of no value to me. The reason I usually use a level of concurrency is so the benchmark more closely mirrors real-world usage, and tests the full stack a little better (because PHP by itself is nice to benchmark, but very few sites are run on top of PHP alone!).Īnyways, I re-ran all the tests using -c 1, and am publishing the results below: Environment Sometimes, the use of concurrency ( -c 10 in the above case)(to simulate concurrent users hitting the site at the same time, can cause benchmarks to be slightly inaccurate. PHP 5.6, PHP 7, and HHVM running Drupal 8.0.1, uncached and some graphs of the above data: PHP 5.6, PHP 7, and HHVM running Drupal 8.0.1, cached # Benchmark Drupal 8 /admin page logged in as user 1.ĭrupal 8 results (concurrency 10) Environment # Benchmark Drupal 8 home page out of the box with default caching options enabled. All tests were run five times, the first two results were discarded (because they often reflect times when some caches are still warming), and the latter three were averaged.Īfter installing Drupal 8.0.1 with the standard installation profile (this is done automatically by Drupal VM), I logged in as the admin user (user 1), then grabbed the admin user's session cookie, and ran the following two commands: Using the above notes, you can exactly replicate this benchmarking environment should you desire. Therefore, I'll submit my own PHP 7 vs HHVM benchmark here, using the following versions:Īll tests were run using Drupal VM version 2.1.2 with VMware Fusion 8.1.0, on my mid-2013 MacBook Air 13" 1.7 GHz i7 with 8GB of RAM. This was my main concern too, as there wasn't enough detail in the benchmarking article to determine what exactly was the system under test. Should potentially reveal something interesting. ![]() Would be interesting to see the result comparing the benchmark with/without caching enabled in Drupal 8. If you did not turn that off, then it is probably a reason to why the PHP 7 boost isn't bigger. ![]() Standard installation for Drupal 8 has cache on as default. In the comments on that post, Thomas Svenson mentioned: ![]() The results are pretty damning for PHP 7: Naming a benchmark that way certainly makes the general PHP populace take it seriously! One benchmark that really stood out to me (in that it seemed so wrong for Drupal, based on my experience) was The Definitive PHP 7.0 & HHVM Benchmark from Kinsta. ![]() Wordpress 4.4 Results ('bare metal', concurrency 1)Īs PHP 7 became a reality through this past year, there were scores of benchmarks pitting PHP 7 against 5.6 and HHVM using applications and frameworks like Drupal, Wordpress, Joomla, Laravel, October, etc.Drupal 8 Results ('bare metal', concurrency 1).Both PHP 7 and HHVM blow PHP ≤ 5.6 out of the water. PHP 7 is actually faster than HHVM in many cases, neck-in-neck in others, and slightly slower in others. Tl dr: Always test your own application, and trust, but verify every benchmark you see.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |