As the least technical member of the RipCloud team, I thought it’d be good to try my hand at the Bitnami WordPress Amazon Machine Instance (AMI). I spent a few months installing and hosting a few of my WordPress sites on an Amazon Cloud EC2 instance. As other users have noted, it has been a challenging experience. Below are a few of the issues I’ve faced.
WordPress Directory Location
It seems that Bitnami is using a standard LAMP setup for all their AMIs then simply adding a directory for each application directory. Therefore, the default location for the WordPress install was domain.com/wordpress. Not ideal if you want to actually build a business site or multi-site install of WordPress. Again, I’m not the apache guru on the team so it it took me a few hours of mucking with apache configurations to get the WordPress directory as my default.
It appears that Bitnami uses the same apache configuration for every instance size vs optimizing for micro, small, medium, etc… I ran into a few issues with Apache starting up too many http processes for a micro instance and had to configure it specifically for a micro instance.
Apache / MySql Contention
The dynamic nature of WordPress requires some significant MySql usage and eventually the contention on the micro instance made it almost unusable with the Bitnami AMI. Just poking around in the WP-admin tool eventually used all my CPU % and ramped up the CPU ST (steal time) to 80%-90%. While IBM defines Steal Time as “the percentage of time a virtual CPU waits for a real CPU while the hypervisor is servicing another virtual processor.” Some users claim this is from other clients on the same machine stealing their CPU, but it’s actually how many cycles were re-claimed by the hypervisor because the virtual machine has reached the maximum allocated number of processor units of the underlying processor core. Basically, you’ve used up all the processing power allocated.
WordPress Bitnami AMI with Steal Time
Keep in mind that this is a load of only a few hundred users per day. Generally I could resolve the issue by restarting apache and MySql and the load would drop temporarily. The long term solution here is likely some MySql tweaks and caching to optimize for the heavy load WordPress places on MySyql. Unfortunately those are beyond my ability so I decided to upgrade from a micro instance to a small instance to see if that resolved it.
Initially the upgrade from the micro instance to a small instance via the BitNami interface seemed to go smoothly. It did require me to start paying Bitnami $30/mo as I upgraded from the free micro instance to the 3-server plan that supports the small instance. Therefore my overall costs (including EC2) jumped from $15/mo to >$80/mo.
Unfortunately when the instance was upgraded it changed the WordPress site locations in MySQL databases so I could no longer access or log in to my WordPress site. I had to get one of our technical gurus to come in and update all those settings in the MySql database. I believe this was done via the “updateip” file in the WordPress directory, likely to resolve any issues in case the IP address had changed during the upgrade process.
I’ve seen less MySql contention on the small instance but I still believe the micro should have been able to handle sites with a couple hundred users if optimized well.
I am actually a big fan of the Amazon Cloud and the idea of the AWS marketplace to create a simple “WordPress appliance” for non-techies like me. There is no reason why it should be this difficult nor cost me $80/mo for a simple cloud-based WordPress solution.