infrastructure-update

Everything started on Heroku in October 2012 over their dynos with Heroku Postgres and continued on OpenShift in August 2013 over a LAMP stack based on Apache 2.4, PHP 5.3 and MySQL 5.1.

Now it’s time to to move my little blog on a modern stack. Best offer on OpenShift is a variation of the standard LEMP (we can call it: LEMP-HH) stack with HHVM 3.8, MariaDB 5.5 over NGINX 1.7.

lemphh-stack

Actually biggest performances improvement was achieved adding a good cache plugin a few months ago. I always used W3 Total Cache and WP Super Cache but, in this specific case, they are both complex to use because of the structure of OpenShift stack. Best solution I found is WP Fastest Cache plugin, one of the latest cache plugin I tested. Here is the stunning header of their website showing two beautiful cheetahs (are they cheetahs?).

wp-fastes-cache

Anyway coming back on new stack, there is no official bundle yet but you can create a new application using tengyifei’s HHVM 3.8 cartridge and adding OpenShift MariaDB 5.5 cartridge. I wasn’t able to run them on different gears (with scaling option activated and HAProxy) but seems fast enough on a single gear.

Filesystem structure is similar to the standard PHP bundle except for the application dir that is named www/ instead of php/. I used last backup from UpdraftPlus to migrate database on MariaDB. On non scalable applications you need to forward port in order to access DB from your local machine. RHC command is:

rhc port-forward -a application-name

Source here: Getting Started with Port Forwarding on OpenShift

Moving on NGINX also causes problems on permalinks because .htaccess doesn’t work anymore. The Nginx Helper plugin fix the problem but you could simply add a couple of row to NGINX configuration located in /config/nginx.d/default.conf.erb.

# Handle any other URI
location / {
try_files $uri $uri/ /index.php?q=$request_uri;
}

Discussion on WordPress support forum: WordPress Permalinks on NGINX

Refactor of previous filesystem, migration of database and bugfix of permalinks and other stuff takes about 2 hours and, at the end, everything seems working fine. I’m quite confident this a future proof solution but I’m going to test it until next major update 🙂

[UPDATE 2015-09-06 21:56 CEST]

After migration sitemap_index.xml and robots.txt weren’t reachable. Some rules were missing. I took the opportunity to switch to Yoast SEO for sitemap, Facebook open graph and Twitter cards. Then, these rules fix problems with SEO.

# Rewrites for WordPress SEO XML Sitemap
rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
# Rewrites for robots.txt
rewrite ^/robots\.txt$ /index.php?robots=1 last;

A  couple of weeks ago I was playing with Hack looking for online resources. I found on Youtube the playlist of the Hack Dev Day 2014 where Hack was officially presented to the world.

Introduction to the language by Julien Verlaguet is really interesting, it show the advantages of static typing and how the HHVM is able to preserve the rapid development cycle of PHP.

Also talk by Josh Watzman is interesting. He talks about how to convert PHP code to Hack code and years of experience at Facebook are extremely useful.

The conference also talks about how to run HHVM on Heroku, gives an overview of library and common use cases of Hack and talks about HHVM strong optimization.

If you are playing with Hack I absolutely recommend these videos.

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 😀

I talked about AppFog in a previous post listing a number of advantages compared to Heroku. At the end of March 2013 AppFog removed support for custom domains on the free plan. Supported domains are limited to *.af.cm. This is a huge problem if you are using AppFog to host small websites who rely on the free plan. People aren’t happy.

Their solution is to use the “small” plan for 20$/month!! Many housing provider offer a SSD VPS for 20$/month. 240$/year for a little website is too much. I planned to host a small blog on AppFog and when I faced the problem I was very sad.

After some hours spent on Google I found this: https://github.com/yukinoraru/heroku-http-reverse-proxy. Is a scaffold to use Rack Reverse Proxy on Heroku.

You can use an Heroku app as entry point and route all requests to AppFog application. Performances are not so bad as you can think and everything seems works fine.

heroku-appfog-proxy

heroku_appfog

A few months ago I migrated my personal website (a single page with a bunch of links served by Sinatra) from Heroku to AppFog. I did it because Heroku service has one big limitation: you can’t point a root domain to a Heroku app. Actually there are some workarounds to do it but Heroku discourage them.

AppFog is quite different from Heroku. It allows you to point your root domain to their app (see blog post and docs about that). It doesn’t use GIT for deploy, it uses a command line tool called af who transfers your code from e to the cloud and perform management operations (actually really similar to Heroku toolbelt).

Setup is done using one of the available Jumpstart, a ready-to-go scaffold for your needs. There are jumpstarts for Rails, Sinatra, Django, WordPress and more. In addition you can choose several add-ons (many of those are also available on Heroku). The free plan offers you 2GB of memory with no limits. It’s enough for personal use.

Another advantage is the lack of idle. Heroku Dynos goes idle if you app isn’t accessed for a while. My site has 5-6 accesses per day so it’s idle for each request… AppFog seems not affected by this problem, probably works in a different way.

If you website is small and has low traffic my advise is to use AppFog.

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 🙂