Check out Why I don’t host my own blog anymore.
I mentioned it to a friend and he immediately piped in “Oh that guy did it wrong, he shouldn’t care about KeepAlive, he needs FastCGI”.
Ok so the guy “messed up” and misconfigured his blog. Zigged instead of zagged. Bummer.
But it doesn’t have to be this way. Right now we offer Wordpress as a juju charm. This lets us deploy Wordpress with Mysql in 4 commands.
However if you look at the db-relation-hook we don’t do anything special, we create an apache vhost and set it up for you. While this is simple, there’s no reason we can’t make this charm be a turbo charged deployment of Wordpress. Let’s look at some of the recommendations we see on his blog and on HN:
- A simple caching plugin would have quickly fixed this for you.
- In my stacks I always use nginx in conjunction with Apache to handle as much of the static content load as is possible and that lifts a huge weight from Apache. Next up is to always use a bytecode cache like Xcache or APC, these help give a huge boost in performance.
- But then you hit a wall, next up are limitations in WP SQL and MySQL, these can be helped by messing with the queries and using Memcached also helps to significantly boost the DB performance here.
- I had similar nightmares to you for a long time with Apache/PHP/WP, then finally put Varnish cache in front of the whole thing.
- And someone recommends just shoving the thing in Jekyll and serving that.
I’m sure everyone will have an opinion on how to deploy Wordpress. From an Ubuntu perspective, we ship the wordpress and mysql packages, but that only gets you so far. It’s still up to you to configure it, and as this guy proves, you can mess something up. Wouldn’t it be nice if we could collect all the experience from people who are Wordpress deployment experts, put that in our charms and just give people that out of the box?
We could use nginx in the Wordpress charm, with FastCGI, we can certainly add relations to make varnish and memcached know what to do when they’re related to wordpress. And/or just “juju add-relation jekyll wordpress” and have that Just Work.
These are the kinds of problems we’re trying to tackle with juju. Will it be totally perfect for everyone’s deployment? Of course not, that’s impossible, but we can certainly make Patrick’s experience more uncommon. People will always argue about the nitnoid implementation details, but we can make those config options; the point is that we can share deployment and service maintenance as a whole instead of hoping people put the lego blocks together in the right order.
Interested in turning a plain boring charm into something sexy? I’ve filed the bug here, let us know if you’re interested.