Amazon EC2 Bitnami Wordpress Extremely Slow

Question

I've encountered several issues with Amazon EC2 & Bitnami Wordpress AMI (RedHat) on small instance.. and honestly I don't know who to ask :) I'm not a SysAdmin/Linux expert, but I've learned basic SSH commands and other things required to keep going for a basic start.

So here's what is happening:

Wordpress website is loading extremely slow - PageSpeed & YSlow score is 27 of 100. I think this is caused by memory_limit in php.ini. When I installed Bitnami Wordpress AMI, imported WP Users, set the theme and other basic things, I wasn't able to even access wordpress website - just a blank page showed up. After few solutions, I've tried increasing php.ini memory_limit from 32M to 128M (Max). And I've increased WP memory limit to 64M.

Website loaded properly and users were able to access it - but it's extremely slow. When I try decreasing php.ini memory limit to 64M, website shows up a blank page again.

Only thing that I can think of currently is increasing EC2 instance from .small to .large or similar. Please let me know your thoughts on this issue.. and many thanks!

Answer 1

Since you have not received an answer yet, allow me to summarize my comments into something that is hopefully useful:

• Profile your application to understand where the time is being spent.

Some areas you can affect are:

• PHP needs RAM, but so does your database (I know nothing about Bitnami, but Wordpress uses a SQL database for storage).
• Allocate enough RAM to PHP. Seems like that's somewhere between 64MB and 128MB.
• If you are using MySQL, edit my.ini. If you're using a default configuration file for MySQL, the memory allocation parameters are dialed way too low. If you post your my.ini file, I can give suggestions (or if you're using a different database, state which that is).
• Consider striping multiple EBS volumes for your data partition.
• Use an EBS backed instance if you are not already.

You can make a more informed decision about where to tune if you have profiling results in hand.

Answer 2

I would suggest to use a Cache tool. The first one that you can try is APC (Alternative PHP cache). It is easy to install in Red Hat: yum install php-pecl-apc. You can get much better results with a WordPress specific cache plugin like W3 Total Cache or Super Cache. I use the last one and it is easy to install in WordPress application:

1. Install Super Cache from the WordPress admin panel
2. Change the .htaccess permissions: sudo chmod 666 /opt/bitnami/apps/wordpress/htdocs/.htaccess
3. Enable the plugin and follow the configuration steps. You can see how this plugin modifies the .htaccess file
4. Configures the cache options according to your preferences and test it. You can do performance tests using a service like blitz.io
5. Change the .htaccess permissions to 600 when everything is ok.

I hope it helps.

Answer 3

We saw something similar. For us, the opportunity cost of our time fiddling with optimization settings was much higher than just going with a dedicated Wordpress hosting provider.

The leaders in this space (dedicated Wordpress hosting) appear to be WP-Engine and a few others like Synthesis

http://trends.builtwith.com/hosting/wordpress-hosting

I had my personal site on dreamhost but they ended up becoming worse and worse over the years so I moved to bluehost, which has been ok.

Overall, I think EC2 is great but it requires a lot of fiddling. Depending on the cost of your time and area of expertise, you might choose to switch to a more specialized provider.

I have no affiliation with any of these companies other than my personal experience being an individual shared hosting customer at both dreamhost and bluehost.

Answer 4

We had a similar problem with a Php/MYSQL Application which we moved to an EC2 instance connecting to an RDS database instance. Pages were taking 10x longer to load than on our previous server, even though all specs were the same, i.e. number of CPUs, RAM, clock speed, and the versions of Php/Apache were identical.

We finally found the cause of the problem, the default setting for an RDS database for the Cache query size is 0. This causes the database to run extremely slowly. We changed the query_cache_size to be 1000000000 (1G) (as the RDS instance had 4G of RAM) and immediately the application performance was as good as our previous (non-AWS) server.

Secondarily, we found that an EC2 server with MySQL installed locally on the server did not perform well, on the Amazon Linux build. We tried the same thing on an EC2 instnace running Ubuntu, and with a local MySQL database the performance was great.

Obviously for scalability reasons we went with using an RDS instance but we found it interesting that moving the MySQL database onto the EC2 instance radically improved the performance for an Ubuntu linux EC2 server but made no difference with the Amazon Build of Linux.