Since we’re just about to 11.04 beta2, I figured its high time I start using Ubuntu Server for my personal blog.
What? Almost a year at Canonical and my blog wasn’t on Ubuntu server? Well, for over 5 years now, a personal friend has provided me with a free Xen virtual machine to run my blog on. I migrated it off of Debian then, which was sad for me, but back then I was so focused on working I didn’t have time or resources to be picky, so I said OK.
Fast forward to now, I’ve been working on Ubuntu Server and getting ribbed by my co-workers about that “crappy CentOS xen box” they’d see me logged into.
Well thats all over now. I decided to marry all the new tech I’ve been playing with lately into one glorious blog migration.
The old blog was:
- Xen domU
- 500MB RAM allocated
- 9GB storage
- CentOS 5.5
- Apache + mod_php (5.3.5 from IUS project)
- MySQL 5.0.77
- WordPress 3.0.5 manually installed single-site
The new hotness is:
- EC2 t1.micro (its upgradable!
- 692MB RAM
- 8GB EBS
- nginx + php5-fpm (5.3.5 from natty)
- Drizzle 2011.03.13 (wordpress-plugin 0.0.2)
- WordPress 3.0.5 from natty in multisite mode
The steps to migrate weren’t altogether complicated. A bit of configuration for nginx to have it serve my PHP using php5-fpm, and copying most of wp-content over. Drizzle couldn’t have been more straight forward:
- Install drizzle7-client from EPEL on CentOS vm
- drizzledump blog database (drizzledump automatically converts mysql schemas to drizzle compatible ones)
- load it into drizzle on Ubuntu server
WordPress still needs *some* help to use Drizzle. Much of this will be handled by the wordpress-drizzle package from my ppa (add-apt-repository ppa:clint-fewbar/drizzle) which filters DDL to change things like LONGTEXT to TEXT. Because Drizzle has done away with the eeeeevil of datetimes with 0000-00-00 as their date (a non-existent date), we need to change all instances of that to ’0001-01-01′. In the future I’d like to see this abstracted out of wordpress even more so that it is more aware of the datetime fields and can use actual NULL values. I believe this can be done in the plugin by overloading the insert/update methods. I’ve begun working on that, but for now I’ll just have to keep patching wp-includes/post.php , which seems to be the main user of 0000-00-00 to denote a “draft” post.
We also have to alter the wp_posts table slightly. Thats because wordpress relies on mysql’s broken “NOT NULL” producing an “empty string” in varchars. This ALTER does that:
ALTER TABLE wp_posts MODIFY COLUMN post_mime_type VARCHAR(100) COLLATE utf8_general_ci DEFAULT '';
Anyway, goodbye CentOS, hello Ubuntu!
This is a test comment to prove commenting works.
Would you please explain this part of your setup:-
nginx + php5-fpm
Sure. In the old server I used the traditional model of Apache with mod_php to serve all requests. This meant all static requests and PHP requests went through a server with the full capabilities for php.
Now I’m using Nginx, which is an incredibly light weight, high performance HTTP server, and then running PHP 5.3′s “fpm” SAPI as a daemon which nginx contacts using the fastcgi protocol. The difference in page load times isn’t really huge, but the impact on the server is:
On the old box:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
apache 3476 0.1 5.8 46220 27152 ? S Apr12 0:44 /usr/sbin/httpd
apache 5839 0.0 2.4 31800 11412 ? S 03:51 0:00 /usr/sbin/httpd
apache 7304 0.0 5.1 43788 23724 ? S 03:10 0:01 /usr/sbin/httpd
apache 21028 0.0 5.6 46064 26212 ? S Apr12 0:19 /usr/sbin/httpd
Note that I could only run 4 – 5 of these httpd’s at once because of the growth potential of them, so sometimes static requests would queue up.
On the new server, nginx and fpm scale independently, so I can tune them accordingly.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
www-data 6809 0.0 0.3 71896 2392 ? S 04:41 0:01 nginx: worker process
www-data 6810 0.0 0.4 72188 2648 ? S 04:41 0:01 nginx: worker process
www-data 6811 0.0 0.4 72316 2912 ? S 04:41 0:01 nginx: worker process
www-data 6812 0.0 0.3 71896 2392 ? S 04:41 0:01 nginx: worker process
www-data 6135 0.1 6.6 180308 40068 ? S 03:56 0:26 php-fpm: pool www
www-data 6136 0.1 6.8 181516 41248 ? S 03:56 0:27 php-fpm: pool www
www-data 6138 0.1 7.3 185348 44876 ? S 03:56 0:25 php-fpm: pool www
www-data 6139 0.1 6.8 181688 41432 ? S 03:56 0:33 php-fpm: pool www
www-data 6140 0.1 6.6 180812 40560 ? S 03:56 0:28 php-fpm: pool www
www-data 12019 0.1 6.5 181260 40008 ? S 05:09 0:23 php-fpm: pool www
www-data 12366 0.0 7.0 183012 42500 ? S 05:41 0:18 php-fpm: pool www
www-data 13701 0.0 4.8 171216 29688 ? S 07:44 0:07 php-fpm: pool www
www-data 13705 0.0 6.7 182028 40956 ? S 07:44 0:08 php-fpm: pool www
www-data 13706 0.0 7.3 185780 44516 ? S 07:44 0:07 php-fpm: pool www
www-data 13714 0.0 6.8 182992 41676 ? S 07:44 0:07 php-fpm: pool www
www-data 13715 0.0 6.7 182252 41080 ? S 07:44 0:06 php-fpm: pool www
www-data 13716 0.0 6.7 182512 40908 ? S 07:44 0:07 php-fpm: pool www
Its also worth noting that the old box is i386 while the new one is amd64, making pointer sizes larger among other things.
\o/
I also use Ubuntu Server 11.04 for my webhosting. I do not use the Ubuntu wordpress package as it lags behind (upstream is at 3.1.1). And as it only needs to be plopped on the hard drive with a database and some minor configuration to httpd.conf (or similar) which you’d be doing anyway, the Debian packaging doesn’t really add any value to me.
Also, I use 32-bit for my webserver since RAM is precious there as I pay for hosting.
Good point about using 32-bit when you are mememory sensitive. PHP seems especially wasteful when it comes to pointers, which are the biggest waster or space on 64-bits. That said, chosing 64-bits now means I can upgrade this t1.micro to a much bigger instance and use all of the RAM effectively if need be (though I can’t possibly see why my blog would necessitate that