Continuing on from part one in our series, now that we have a working HHVM environment, we can start to use it for something more practical than
One of the first things you can do today to improve your workflow, is to start using HHVM for composer. As noted in numerous tweets. This will make composer run faster, and use less resources. And, as this is a standalone process, it is easy to switch away from PHP.net -- and more importantly, switch back if things go awry.
First, lets start by installing Composer. Because HHVM defaults to a 5000ms HTTP request timeout, we will want to change this setting.
To change this, we need to set the
Http.SlowQueryThreshold configuration option.
We can set it in the
server.hdf config (affecting all requests) by adding:
Or, we can do it via the command line using the
-v flag, or if using
--php flag to emulate PHP's CLI, the
Note: You may require a higher threshold depending on your internet connection
We then have to install a couple of dependencies:
Now to install Composer, we can simply do:
This uses the
--php flag to allow us to pipe the Composer installer code directly into HHVM.
Next, we setup an alias for composer to allow us to run it via HHVM, and to set two network configuration variables to alleviate most issues with slower connections.
Additionally, we set the
Eval.Jit=false as the JIT is only beneficial to long-running processes when used on the CLI, and would in the case of composer cause the HHVM startup to be slower.
To make this permanent, you should add this line to
~/.bashrc and run
We can then run
composer and setup our project, using for example the Zend Framework 2 Skeleton Application:
Note: I got an ErrorException "Undefined variable: inputStream", however it completed successfully none-the-less.
Setting up our Web Server for Zend Framework 2
Next, we update our Nginx and hhvm server configurations to point to the ZF2 document root,
For Nginx, edit
/etc/nginx/sites-available/hhvm.conf and change the following two lines:
For HHVM, we change the
Server.SourceRoot configuration to:
Next, restart both services:
Note: prior to the HHVM 3.0 the init scripts for Ubuntu (at least) were broken. Instead, you should use
sudo killall hhvm && sudo service hhvm startto restart.
If you access the web server in your browser again, you will see the default ZF2 Skeleton Application:
Now you can start to develop a new ZF2 application.
Another common task that can be improved by switching to HHVM is running your unit tests.
To do this, first install PHPUnit using Composer:
To complete the installation, add the following alias to your
~/.bashrc and run
phpunit command will be run via HHVM, just like Composer.
If we want to run the ZF2 test suite, we can do so by running the following:
Using FastCGI with UNIX Sockets
With the next version of HHVM (3.0, scheduled for March 27th) we will see support for FastCGI over UNIX sockets.
UNIX Sockets should (in theory) perform better than TCP sockets, and are easy to use. If you choose to make this change, be sure to benchmark before and after the change to ensure that you are actually seeing performance increases, or resource usage decreases.
To use UNIX sockets, we again need to change our server configs. For HHVM, change
/etc/hhvm/server.ini like so:
For Nginx, change
Then just restart the daemons again:
Note: To use this feature now, you must install a current nightly build (the
VagrantFilewill do this by default).
Coming up next...
As well as an overview of using HHVM to replace PHP.net, we now have two practical applications for HHVM that we can put into use immediately.
In the next part in this series, we will take an in-depth look at hack and the features it brings to the table — as well as review what they might mean for PHP.net.
Have you tried HHVM yet? What are your experiences? What do you think about HHVM so far? Let us know in the comments.