Viewing hosting View all News

HHVM: The Gift That Keeps On Giving

Over the past 20 years, PHP has become the de facto server-side programming language of the web.

From leading open-source software like WordPress to some of the Internet’s most heavily-trafficked sites (Facebook, Twitter, and Wikipedia to name a few), you’ll find it everywhere.

But its developer-friendly syntax comes at a cost.

Before any Web Magic™ can happen, the human-readable PHP source code must be run through an interpreter. This process is expensive (particularly in terms of memory usage) and time-consuming. Ultimately, this sets an upper-bound on the number of simultaneous page requests a given server can handle. As a site nears this ceiling, it becomes necessary to either make the site more efficient, or upgrade the hardware.

For some sites, the answer is to sidestep PHP altogether and implement static page caching. But for others, where dynamic processing is unavoidable, the solution might lie in the interpreter itself.

As system administrators know, there is no shortage of PHP interpreters on the market.

Each has its own quirks, configurations, and compatibility issues, so there is no one-size-fits-all solution. But with a little experimentation and a lot of testing, performance gains can be substantial.

One of the most promising interpreters available today is the Hip-Hop Virtual Machine (HHVM). Developed in-house by Facebook, the name of the game for HHVM is speed. For one thing, HHVM meets the machine halfway, converting PHP source code into an intermediate bytecode (this bytecode, then, is what’s left to dynamically interpret at runtime).

This is similar to what PHP extensions like Xcache bring to the table. Another trick up its sleeves: HHVM uses a single multi-threaded process to handle requests (unlike, for example, PHP-FPM, which spawns multiple processes). This leads to much more stable CPU and memory usage for servers operating under heavy loads.

A couple months ago, one of the more resource-heavy sites managed by Bright Bright Great was suffering from a substantial increase in traffic. While publicity is one of the better problems to have, it did pose difficulties for the server, which simply wasn’t configured for that level of interest.

After some (read: lots of) compatibility testing, we successfully transitioned from PHP-FPM to HHVM. The results were astounding.

The average DOM-Ready time dropped by 46%. Simultaneous page serves increased by 112%. And CPU usage under load, once maxed out, remained stable at a healthy 55%.

In fact, the PHP gains were so successful the bottleneck was shifted to MySQL. After some code rewrites to help the site take advantage of object caching (via HHVM’s implementation of APC), the simultaneous page serving capacity was nearly doubled again.

But wait, there’s more!

As part of HHVM’s regular development cycle, its engineers are locked in a room with a surfeit of junk food and coffee (I imagine) and tasked to further optimize the code already in place. By focusing on improvements that directly benefit widely-used software, the real-world impact of any gains made is maximized. With the recent release of version 3.8, HHVM was able to serve 9.7% more pages per second for WordPress, 4.8% for MediaWiki, and 13.9% for Drupal8 (uncached).

We ran quick before and after tests ourselves (against the site previously mentioned) using the command line program siege. Sure enough, the upgrade was able to serve 4.3% more pages per second.

HHVM is indeed the gift that keeps on giving!

Posted By
Josh Stoik

How To Achieve an A+ SSL Configuration on Nginx

Qualys SSL Labs has a wonderful tool to help evaluate your server’s SSL configuration. I recommend you take a moment to scan your site and see how you fare. Go do that now. I’ll wait. If you didn’t get a perfect score, you aren’t alone.

The default configurations for popular server-side software like OpenSSL often support cryptographically weak standards that can put users at risk. Even major corporations have room for improvement.

Keep your server secure

If you’re on a shared server or at the mercy of control panel software like cPanel or Plesk, unfortunately there isn’t anything you can do. But if you have root access and a little knowing of the command-line, this article will help you harden your configuration so you can get a perfect A+.

While the following examples are specific to Nginx, they should be able to help point any readers running Apache or Lighttpd servers in the right direction.

Obtaining a Certificate

First, let’s start with a quick refresher on how you go about getting a certificate in the first place. Make a directory outside your web root, and once in that directory, generate a private key and certificate signing request (CSR). Your key should be at least 2048 bytes. In this example we’ll generate one that is 4096 bytes. If you have an existing key and can’t remember how strong it is, you can type:

openssl rsa -in domain.com.key -text -noout | head -n 1

To generate a new key, use:

mkdir /var/www/domain.com/ssl
cd /var/www/domain.com/ssl
openssl req -new -newkey rsa:4096 -nodes -keyout domain.com.key -out domain.com.csr

The openssl command will quiz you about your domain and organization. The Common Name (CN) needs to be the fully-qualified-domain-name for which you are purchasing the certificate. Remember, domain.com and www.domain.com are technically two different domains, so enter the CN exactly as visitors are expected to reach it. Some certificates, such as Comodo’s PositiveSSL, are magically valid for both www and non-www variants (aren’t they sweet?).

You should now find two files in your ssl directory: domain.com.key and domain.com.csr. That key is meant to be private, so take a moment to update its permissions. If 600 is too restrictive for your environment, 640 might do the trick.

chmod 0600 domain.com.key

Now go buy a certificate. Namecheap offers decent Comodo certificates from as low as $9, or you could spend more money elsewhere. It doesn’t much matter. As part of the certificate activation process, you’ll be asked for the CSR you just created, so keep that handy. Different Certificate Authorities (CA) have different validation processes, so just follow whatever instructions you’re given.

Once your certificate has been issued, upload them to the directory containing your key and CSR. If you are issued two or more bundled certificates (which is a common practice), they must be stitched together into a single file for Nginx. The order is important, so double-check the CA’s documentation. For Comodo PositiveSSL certificates, run the following:

cat domain.com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > domain.com.combined.crt

Nginx Set Up

By default, OpenSSL uses a weak 1024 byte key for Diffie Hellman key exchanges.  Let’s bump this up to 4096 by running the following command.  It can take a while to complete, so go make a sandwich:

openssl dhparam -out /etc/nginx/dhparams.pem 4096

Now let’s make Nginx’s SSL configuration a little more secure by adding the following code to the http{} block of your /etc/nginx/nginx.conf file:

http {
	...

	##
	# SSL Settings
	##

	## force modern protocols and ciphers
	## and enable ssl cache for a small
	## performance boost

	ssl_prefer_server_ciphers On;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
	ssl_session_cache shared:ssl_session_cache:10m;
	ssl_dhparam /etc/nginx/dhparams.pem;

	...
}

Now that we have the general out of the way, let’s move onto site-specific configurations. Open the configuration file corresponding to your site, something like /etc/nginx/sites-enabled/domain.com.conf.

Let’s start by adding a server block to redirect www.domain.com to domain.com, and also force HTTPS connections for everything. If www.domain.com is your main domain, simply reverse the www and non-www in the following examples.

server {
	listen 80;
	listen [::]:80 ipv6only=on;

	server_name www.domain.com domain.com;

	rewrite ^(.*) https://domain.com$1 permanent;
}

Now in your main server block for the domain, add the following:

server {
	listen 443 ssl;
	listen [::]:443 ssl ipv6only=on;

	server_name domain.com www.domain.com;

	#point to the combined certificate and key we generated earlier.
	ssl_certificate /home/domain.com/ssl/domain.com.combined.crt;
	ssl_certificate_key /home/domain.com/ssl/domain.com.key;

	#enable HSTS (in supported browsers) to make sure all subsequent
	#user requests are done over HTTPS regardless of protocol typed.
	add_header Strict-Transport-Security "max-age=31536000";

	#redirect non-canonical domain over SSL.
	#this will only work if your SSL certificate also covers www.domain.com.
	if ($host = 'www.domain.com' ) {
		rewrite ^(.*)$ https://domain.com$1 permanent;
	}
	...
}

If your server is not configured for IPv6, remove the second listen lines from the above examples. Speaking of IPv6, Nginx only wants to see a single ipv6only=on attribute per port across all your server blocks. If you have additional server blocks defined, simply omit that string from their definitions.

That’s it! Restart Nginx to apply the changes:

service nginx restart

Last Thoughts

You should now have pretty darn good SSL support! But the fun doesn’t end here!

New threats or vulnerabilities can pop up any time, to say nothing of the inevitable march of progress (advances in technology will eventually make your once great setup laughably inadequate).  Make sure you regularly apply any security patches made available to your distribution.  You should also periodically rerun the Qualys SSL Labs scan to see if any tweaks are needed to stay on top.

Posted By
Josh Stoik