About a month ago I wrote about how cool was to migrate to HHVM on OpenShift. Custom cartridge for Nginx + HHVM and MariaDB was running fast and I was really excited about the new stack. I was landing on a new, beautiful world.

About a week later I faced some problems because of disk space. Files took only 560MB over 1GB but OpenShift shell gave me an error for 100% disk usage (and a nice blank page on the home because cache couldn’t be written). I wasn’t able to understand why it was giving me that error. It probably depends on log files written by custom cartridge in other position inside of the filesystem. No idea. Anyway I had no time to go deeper so I bought 1 more GB of storage.

The day after I bought the storage blog speed goes down. It was almost impossible to open the blog and CloudFlare gives me timeout for half of the requests. Blog visits started to fall and I have no idea about how to fix that. Some weeks later I discover some troubles with My Corderwall Badges and Simple Sharer Button Adder but, in the OpenShift environment, I had no external caching system useful to handle this kind of problems.

I didn’t want to come back to MySQL and Apache but also trash all my articles wasn’t fun so I choose something I rejected 3 years ago: I took a standalone server.

server-in-datacenter

First choice was Scaleway. It’s trendy and is BareMetal. 3.5€ for a 4 core ARM (very hipster choice), 2 GB RAM, 50 GB SSD server. New interface is cool, better then Linode and Digital Ocean, server and resources are managed easily. Unfortunately HHVM is still experimental on ARM and SSD are on SAN, and they aren’t so fast (100MB/s).

Next choice was OVH. New 2016 VPS SSD (available in Canadian datacenters) are cheap enough (3.5$) and offer a virtual core Xeon with 2 GB RAM and 10 GB SSD. Multicore performances are lower and you have a lot of less storage but is an X86-64 architecture and SSD is faster (250 MB/s). I took this one!

Unfortunately my preferences aren’t changed since my first post. I’m still a developer, not a sysadmin. I’m not a master in Linux configuration and my stack has several running parts and my blog was still unavailable. My beautiful migration on cutting edge technologies became an emergency landing.

Luckily I found several online tutorial which explain how to master the WordPress stack. In the next days I completed the migration and my new stack now runs on: Pound, Varnish, Nginx, HHVM, PHP-FPM and MariaDB. I hope to have enough time in the coming days to publish all the useful stuff I used for configuration.

For the moment I’m proud to share average response time of the home page: 342ms 🙂

hiphop_logoHipHop was one of the most notable thing came from the Facebook labs about PHP development. PHP is slow and limited. They can’t rewrite theirs entire codebase so they decided to make PHP better. HipHop is a simply PHP to C++ compiler (HPHPc). Converted code is compiled into a binary and performance improvements are about 6x.

Unfortunately HipHop has several downsides. For all the performance gains that HPHPc provided, the curve for further performance improvements had flattened. HPHPc did not fully support the PHP language, including the create_function() and eval() constructs. HPHPc required a very different push process, requiring a bigger than 1 GB binary to be compiled and distributed to many machines in short order.

hhvm_logoTo overcome these problems Facebook develops, starting from early 2010, the HHVM: a PHP virtual machine. HHVM builds on top of HPHPc, using the same runtime and extension function implementations. HHVM converts PHP code into a high-level bytecode. This bytecode is then translated into x64 machine code dynamically at runtime by a just-in-time (JIT) compiler similarly to C#/CLR or Java/JVM.

hack_logoFacebook also released Hack, a programming language for HHVM that can be seen as a new version of PHP which it allows programmers to use both dynamic typing and static typing.

HHVM supports major PHP open source projects like WordPress. Running this project on seems really easy. A little modification was needed but last version (3.9) no longer need this. HHVM can also run on Heroku using a custom buildpack available here: https://github.com/hhvm/heroku-buildpack-hhvm.

My first experiment was to run WordPress on Heroku using HHVM. First step is create a Heroku app using HHVM buildpack:

heroku create --buildpack https://github.com/hhvm/heroku-buildpack-hhvm

Then you can deploy a standard WordPress installation adding the following config.hdf (the HHVM configuration file)

Server {
DefaultDocument = index.php
}
Eval {
Jit = true
}
VirtualHost {
* {
Pattern = .*
RewriteRules {
dirindex {
pattern = ^/(.*)/$
to = $1/index.php
qsa = true
}
}
}
}
StaticFile {
FilesMatch {
* {
pattern = .*.(dll|exe)
headers {
* = Content-Disposition: attachment
}
}
}
Extensions {
css = text/css
gif = image/gif
html = text/html
jpe = image/jpeg
jpeg = image/jpeg
jpg = image/jpeg
png = image/png
tif = image/tiff
tiff = image/tiff
txt = text/plain
}
}

Warning: don’t miss a newline character on the last line or linter will fail and you will going to hate this project 😉

Everything works fine. You can add you favorite MySQL hosted service and run your WordPress 5 minutes installation. Almost every plugin seems 100% compatible, I tested most popular with no problem. Performances are better and you also have the opportunity to use Hack to develop new custom plugins.

Now I’m curious about how HHVM can improve my production installations of WordPress. About this I’m looking for an OpenShift cartridge for HHVM or someone want to collaborate to create a new one (the only I found on Github seems “young”). Anyone interested? Let me know!

It’s about half an year I want to move my blog away from Heroku. It’s the best PaaS I ever used but the free plan has a huge limit: the dynos idle. In a previous post i talked about how to use Heroku to build a reverse proxy in front of AppFog to avoid theirs custom domain limit but the idle problem is still there. My blog has less than 100 visits per day and almost every visitor has to wait 5-10 seconds to view home page because dynos are always idle.

openshift_logoToday I decided to move to another platform suggested by my friend @dani_viga: OpenShift. It’s a PaaS similar to Heroku which use Git to control revision and has a similar scaling system. And the free plan hasn’t the idle problem and it’s 10 times faster!

I created a new application using the following cartridge: PHP 5.3, MySQL 5.1 (I’d like to use MariaDB but cartridge is still in development and I couldn’t install it) and phpMyAdmin 3.4. They require a Git repo to setup application and provide a WordPress template to start. I used it as template moving code of my blog into /php directory.

The hard part was to migrate my PostgreSQL database into the new MySQL. To start I removed PG4WP plugin following installation instruction in reverse order.

Then I exported my PostgreSQL database using heroku db:pull command. It’s based on taps and is really useful. I had some problems with my local installation of MySQL because taps has no options about packet size and character set so you must set them as default. I added a few line to my.cnf configuration:

# enlarged, before was 1M
max_allowed_packet = 10M
# default to utf-8
skip-character-set-client-handshake
character_set_client=utf8
character_set_server=utf8

At the end of the pull my local database contains a exact copy of the Heroku one and I can dump to a SQL file and import into the new MySQL cartridge using phpMyAdmin.

The only problem I had was about SSL certificate. The free plan doesn’t offer SSL certificate for custom domain so I have to remove the use of HTTPS for the login. You can do in the wp-config.php setting:

define('FORCE_SSL_ADMIN', false);

Now my blog runs on OpenShift and by now seems incredibly faster 😀

Yesterday I had to re-deploy the WordPress installation of PrimeGap.net on a new server and, looking for some tips about configuration, I found a new strange buzzword: LEMP Stack. 

We all know the LAMP Stack and we all know it’s old, slow and hard to scale. It includes any distribution of Linux, Apache with PHP as a module and MySQL 5.x.

A LEMP Stack is a bit different. First of all it uses nginx (pronounced “engine x”) and this explain the “E”. Then you can replace MySQL with any of the other fork. I personally use MariaDB 10.0. Many people also use Percona.

You can also replace PHP with another language such Python or Ruby but if you still use PHP choose PHP-FPM.

Many hosting provider provide useful guides to setup you server:

Linode is a bit different and uses PHP-FastCGI. Both uses MySQL. If you, like me, prefer MariaDB following guides should help you:

Current version of WordPress is easy to run on it. WordPress Codex provides a custom configuration to uses nginx. There are many optimization you can do. This Gist seems well done: https://gist.github.com/tjstein/902803

Welcome to the next-gen 🙂

When your WordPress blog gets bigger and traffic grows you have to handle cache. No excuse: is a fast, cheap and optimized way to deal with traffic problems.

W3 Total Cache and WP Super Cache are the most popular plugins to handle cache on WordPress which works well but I don’t like them. They are a good choice only if you don’t have many customizations or some hardware constrain. Recently I had many problems with both two because of other caching systems and some problems on the server.

Now if I have to activate cache on a production stack formed by Apache + PHP-CGI + WordPress I certainly choose nginx.

Using nginx you can activate a fully customized cache layer in front of your website. Unfortunately WordPress doesn’t support nginx cache natively. You need a plugin to deal with it: the WordPress Nginx proxy cache integrator. The code is below:

function add_xaccel_header() {
// Set the X-Accel-Expires header to never cache the page
// if it looks like the page needs to be tailored
// for a user.
$user_cookie_there = false;
foreach($_COOKIE as $key => $value){
if( preg_match('/wordpress_(?!test_cookie)|comment_author|wp-postpass/', $key) ){
$user_cookie_there = true;
}
}
if($user_cookie_there){
header("X-Accel-Expires: 0");
}
}
add_action('init','add_xaccel_header');

The plugin sets a cookie to enable nginx to discriminate between logged and guest user and not cache pages for authors. Default behavior for nginx is to not cache any pages if a cookie is set.

After you had set this plugin you can put nginx in front of Apache. The authors of the plugin suggest an optimal configuration but I prefer a simpler one written by my friend @dani_viga on his blog.

[UPDATE 2013-03-05] Look at the post (finally public :))
http://vfamilyserver.org/blog/2013/02/wordpress-caching-with-nginx/

In addition, to speed up IO (server’s NAS has some latency problems), we use a ramdrive to store cache files. We also had to disable mod_deflate in order to solve some problems when you active gzip compression before nginx.

Now average response time is under 100 ms, static contents are served without Apache and there is no potentially problematic plugin to manage. And purge cache takes less then 3 secs. 😀

Almost every public website rely on Google Analytics for statistics. CloudFlare offers an app to manage the tracking system without edit your own code. It is a very useful feature but has some limitation.

Recently I worked on a network of blog (WordPress-based) available under different (and strange, I know) urls:

  1. http://example.com
  2. http://en.example.com
  3. http://example.com/path/to/blog

Each urls is a different WordPress installation with different content management teams from somewhere in the world which share the root domain. An hour after I had activated CloudFlare the content management teams of blog 2 and 3 reported me a fall of the visits. Websites were online and after 30 minutes of search (and a little headache) we found the problem: The UA code of Google Analytics were all pointed to the one of blog 1.

The CloudFlare app is very useful but doesn’t let you manage custom path and subdomains. It overwrite each occurrence of Analytics code with its own! Use it with caution 😉

After a couple of months spent using and editing this blog’s engine I can say that Heroku’s cloud is not heaven.
Wordpress works like a glance but there are many problems and some of these aren’t easy to solve.

First of all: Heroku is SLOW! I know, I use the free plan but response time is too high. Also the 10$ hosting I used for many years is faster. I think it’s a problem related to Heroku stack. It works well when you use a lot of workers and you have a lot of traffic but when you have less traffic is awfully slow.

Anyway solve this problem is easy: you can use a CDN. Contents are cached and delivered through multiple servers located all over the world. It’s easy and transparent because it works at DNS level. I choose CloudFlare because has a free plan (and we widely use it at @thefool_it). In front of my blog is able to speed-up response time from about five second to less than one.

Another problem comes when you use plugins that try to “activate” itself like Jetpack or Google Analytics plugin. Heroku filters many server-to-server connections and activation through OAuth-like handshake fails. Some plugins offer a “manual” activation wizard, for everything else there’s not solution: you can edit and maintain the plugin’s code or drop it and use another one. Not fun.

Clouds are not heaven (yet).

I’m a developer and I want to start a blog. There are many different engine I can chose: Jekill, Tumblr, Posterous and counting. I choose WordPress because it’s more user friendly IMHO. The problem is: self-hosted or managed?

As usual every choice has pros and cons.

If you choose a self-hosted solution you have to pay for it. Most of times developers can access to a friend’s VPS and deploy there but this require you to setup the environment (nginx, php-fpm, MySQL and so on) and keep everything up to date to avoid intrusions.

If you chose the managed solution you have to pay. WordPress.com offers a free plan but includes advertising and use of plugins is forbidden. The premium plan is better but is 99$ a year.

I tried both solutions. I deployed a version of WordPress on a VPS (thanks @dani_viga). Then you had to install nginx, install php-fpm, configure virtual host, fight against configuration problems, fight against permissions problems, fight against incompatible plugins and finally your new self-hosted WordPress blog is online (and you have a big headache). I’m a developer, not a Sysadmin. I don’t like to refine configuration, keep everything up to date. I just want something easier.

So I tried WordPress.com because I couldn’t find another provider with a free plan. Beautiful site, great wizard for setup blog, everything is up and running in five minutes. I start to write my first post but i didn’t like the syntax highlighter. There is no way to change it. I want to include a custom social streamer. There is no way to do it. I want to customize my template. There is no way to do it… I closed my account. I’m a developer: i don’t like stuff I can’t edit.

One minute before giving up I decided to try one last solution: Heroku. The Cedar stack supports PHP. I searched for a WordPress version ready to deploy on Heroku and I found this. It uses PostgreSQL and, after five minutes of setup, works like a glance. The only problem is the file upload but I solved using the WPRO Plugin (WordPress Read-Only) to upload file directly to Amazon S3.

Now my blog runs in the clouds 🙂