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.
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.
One of the “good problems” I think we have is there’s always things to do. As Charlie Kravetz points out, this can be a bad thing too.
I wanted to post this on Planet to get a better feel for what other people think.
I see my own participation in Xubuntu and Ubuntu development slowing down. Too many events, scheduled on top or close to each other, making it impossible to participate easily.
We are either scheduling too many things, or not checking calendars any more. In past years, it was quite easy to attend all the events held and still participate in development testing.
So for certain things I think we’re doing too much, which is why we’ve streamlined some of the IRC workshops to be shorter. However as I thought of a more detailed answer to Charlie’s concern I came up with the answer (I think).
I don’t think we have too many events, in fact, as we grow the number of events will grow, and our community will need to scale to match that. I am starting to realize that it’s not a bad thing that people can’t find the time to participate in everything.
The real problem isn’t that Charlie doesn’t scale, it’s that someone needs to have his back. So perhaps when events do clash we should look at which teams have what coverage in what events. For example, Charlie clearly needs to do ISO testing, but at the same time Xubuntu should have coverage in developer week because it’s really one of the best places to find new contributors that can …. help Charlie do ISO testing. Catch 22.
So maybe from a team level instead of an individual level we should be focusing on finding people who can jump in when a team is overtaxed for a week. For example, in hindsight maybe we could have done a better job helping Charlie find someone to cover developer week for Xubuntu. A forum thread, a planet post, a tweet, a mention on our Facebook page?
These are all things we could do to help the creaking an overburdened person might face. It’s a bummer that one person can’t scale, but at the same time having different people focusing on different individual things will probably be healthier in the long run.