Previously getting PHP 5.5 or higher set up using the Web Starter Kit involved quite a bit of mucking around with YAML files. One of the big pushes for August was to make that the default version and get things set up to easily update to PHP 5.6 — after all we’re already out of active support for 5.5 and only have security support for another 10 months.

These changes included setting the default version of PHP to 5.5, obviously, but also switching to use OpCache instead of XCache and switching to using MySQL-ND instead of the older MySQL PHP module. There were some additional changes to allow arbitrary setting of PHP.ini settings, which becomes important when talking about OpCache settings as well as other performance enhancements like realpath_cache.

Now that we had the ability to add arbitrary PHP settings one of the first ones we wanted to try out was realpath_cache_size. We all know that some virtual file systems have problems under Vagrant, caching those expensive stats might help out a little bit.

So we ran a few tests comparing various activities you might perform in Drupal and compared how they worked out. These included a cold start request, one where we restarted nginx and PHP-FPM and timed how long it would take; a warm start, which gave the average of a set of requests now that the opcode cache and Drupal cache was warmed up; a cache clearing, which shows how long running “drush cc all” would take; and after cache clear, which shows how long the first request with a warm opcode cache but a cold Drupal cache would take. We compared them with the default realpath_cache attributes — 16k for realpath_cache_size and 120 for realpath_cache_ttl — and updated ones with realpath_cache_size set to 128k and realpath_cache_ttl set to 7200.

What we found was interesting. Using NFS there was a pretty negligible difference, just over 10% drop — from 6.935s to 6.192s — on a cold request and a tiny increase — from 0.602s to 0.617s — on a warm request. Likewise on cache clearing and after were a slight worsening — 1.5% and 0.7% respectively — between the default realpath_cache settings and the updated ones. I suppose this speaks to how effective NFS is at caching files on the client. Another big takeaway is that VBoxFS is really slow. Unfortunately there isn’t a really good alternative on Windows machines. We haven’t tried SMB yet, which I suppose should be our next attempt. But there were some fairly significant benefits to upping the realpath_cache settings there. They worked out to:

• Cold request: from 22.789s to 15.768s (31% drop)
• Warm request: from 3.622s to 2.318s (36% drop)
• Cache clear: from 68.38s to 64.875s (5.1% drop)
• After cache clear: from 17.836s to 12.246s (31% drop)

These tests were performed on a MacBook Pro with 2.3Ghz i7 processor set to allow the VM access to 90% of all 4 cores and 1736M of memory. This was on a site running Drupal 7 on PHP 5.4 with approximately 3,300 files with the extensions .php, .inc or .module.