Got moved to a new server in a new datacenter by Dreamhost this weekend. Seems to be significantly faster than the old one for first page load, like an order of magnitude. It’s more in line with what I get when testing locally. I assume the server I was on was just overloaded. It had often had a load average in the 6’s or 7’s. I had been wondering what was wrong and if I should swtich to VPS. This one’s been at less than one. Hopefully it stays snappy and doesn’t get too loaded up over time.
Dreamhost now has PHP 7, so I’ve switched my main sites to it. Seem at least slightly faster.
On my site, I’m using Apache’s ‘mod_deflate’ and ‘mod_filter’ to compress my compressible responses (mostly text), with a setup based on h5bp’s server config. I got my sites running over HTTPS recently, and today, when looking at my site performance with webpagetest.org, I noticed that my content wasn’t compressing. It was still working fine over HTTP. I noticed in h5bp’s comments that
<IfModule mod_filter.c> could be removed in Apache versions below 2.3.x. I removed it, and sure enough, compression was working again. I’m not sure why it’s different depending on what protocol I use. Perhaps Dreamhost has separate versions of Apache running for the two protocols. Or perhaps it’s just something different about the configuration in the virtual hosts. Regardless, it’s working now. I just hope this doesn’t cause problems whenever they move to Apache 2.4.
I finally set up my site to work with Symfony’s built in HTTP reverse proxy. Took a little bit of time since I had to fix a couple minor bugs in how things are set up with my symfony-initial and Symfony Standard Edition Bundle and then made a mistake in testing whether or not it was working that made me think it wasn’t when it was.
One useful way to test if it’s working is to set the ‘debug’ option of
true (turn this back off for production). This will set an
X-Symfony-Cache header that will provide info on the cache behaviour. You can see these headers on the shell by running
curl -I your.url. If it says ‘fresh’ as part of the header value, that means it was served from the cache. If it shows the header at all, that means AppCache is being used.
For the cache to work, the response must be public and have something set to control how the cache becomes stale. See Symfony’s docs on caching for more details. Since my content rarely changes at the moment, I went with the
Cache-Control header with
max-age. A cool thing about using Symfony’s reverse proxy is that the entire cache will be cleared when clearing Symfony’s cache like normal. This means that if you make a mistake and must remove it from the cache, there is a quick and easy way.