Installing APC cache on Amazon

Micro EC2 instances have about 600mb of RAM, which is not really a whole lot to work with – couple this with a heavy framework such as symfony (which is my preferred framework of choice) and you have an extra layer of complexity every HTTP call.

in order to speed things up, we have a number of options available:

  • op code caching (using APC / E-Accelarator)
  • memory caching (using memcache)
  • reverse HTTP proxy caching (using Varnish)

Op Code Caching

op code caching works by storing the results of a compiled php bytecode in cache, so that subsequent requests will look at the cache and return the compiled result rather than having to revisit the compiler. this can yiel a quick performance win with minimal effort and will be the focus on the article.

Memory Caching

memory caching works like a giant key=>value store in memory where you first check an item exists in the cache, if it does then return it-other get the application to fulfill the request and then store the result in cache, so that subsequent requests will then hit the cache.  memory caching takes quite a lot of planning and you have to be very careful on how you are storing things in the cache. So you have a site with multiple clients, you dont want to return other results from the cache from other clients and therefore need to use a unique means of storing things in the cache (such as a client_id or site_id). this is definately overkill for this operation

HTTP Proxy Caching

HTTP Proxy caching is a layer that sits between your web server process (httpd) and the client accessing the site (your web browser) – the cache will be polled first to see if the HTML and related assets are present, and if not then forward the request on to the web server, store the result in the cache and return the request back to the user. subsequent requests will then hit the proxy which depending on the time to live will return the cached result. This approach can yield quick performance boost, buts its something i’ve never tried before and im hesitant on rolling it out for small(ish) projects.

On to the task at hand…

1. start off by ssh’ing to your web root and create a file with the php_info();

$ vi info_check.php
<?php

// check the current php info settings

phpinfo();

?>

2. open up the php page (http://www.mysite.com/info_check.php in your browser and see if APC is installed

3. if not, then carry on (it wasnt on my default install, perhaps you can get a micro instance with APC already installed!)

4. install APC

$ yum install php-apc

5. check the apc config settings are to your taste, check the PECL manual for APC settings

$ vi /etc/php.d/apc.ini

6. restart httpd

$ sudo /etc/init.d/httpd restart

7. check your PHP config page now for APC and it should be there..

Happy Caching!

Posted in amazon, apc, caching | Leave a comment

Migrating between Amazon EC2 LAMP Servers

following Amazons email about retiring the ec2 hardware, i had to migrate my cousins website over to a new host.. heres the steps i took to get things setup:

start a new t1.mico instance (Amazon Linux AMI) – you should have two instances running, the current site that is hosting your site and the migration destination server for the migration

ssh to the current running site instance (with via the public DNS or elastic IP)

$ ssh -i sshkey.pem ec2-user@address_of_current_server

dump out the mysql database and commit this into svn

$ cd (to project root with svn)
$ mysqldump -uroot -ppassword db_to_backup > /mnt/www/website/db/backup.sql
$ svn add backup.sql
$ svn commit -m "added db backup"

dump out the svn repository on the current host and transfer to new host

$ cd ~/
$ mkdir svn_backup
$ svnadmin dump /path/to/your/repo > /tmp/repo.dump
(transfer to ssh key to the server to allow you to transfer between servers)
$ scp -i /sshkey.pem /tmp/repo.dump ec2-user@(public/elastic IP):/tmp

ssh to the migration destination instance (with via the public DNS or assign a new elastic IP)

$ ssh -i sshkey.pem ec2-user@address_of_migrated_server

change to the root user

$ sudo su

install all the latest security patches

$ yum upgrade

install LAMP

$ yum install httpd
$ yum install mysql-server mysql
$ yum install php php-mysql
$ yum install php-xml php-pdo php-odbc php-soap php-common php-cli \
php-mbstring php-bcmath php-ldap php-imap php-gd$ service httpd start
$ service mysqld start
$ /usr/bin/mysqladmin -u root password 'password'

i usually install svn on the target server, so this needs to be installed too

$ yum install subversion

create the repo on the destination server and import the dump file

$ cd /mnt
$ svnadmin create reponame
$ svnadmin load reponame < /tmp/yourreponame.dump

svn checkout the project into the web folder

$ svn co file:///mnt/reponame

setup the apache vhost as per the svn checked out location

$ vi /etc/httpd/conf/httpd.conf

NameVirtualHost *:80
#
# NOTE: NameVirtualHost cannot be used without a port specifier
# (e.g. :80) if mod_ssl is being used, due to the nature of the
# SSL protocol.
#
<VirtualHost *:80>
  ServerName servername.com
  ServerAlias www.servername.com
  DocumentRoot "/mnt/www/website/web"
  DirectoryIndex index.php
  <Directory "/mnt/www/website/web">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

create and import the mysql database

$ mysql -uroot -ppassword
$ create database db_to_backup
$ mysql -uroot -ppassword db_to_backup < /mnt/www/website/db/db_to_backup.sql

you may need to turn on display errors in the php.ini temporarily if you need to debug any PHP issues and pipe errors to the PHP error log

$ vi /etc/php.ini
...
; Default Value: On
; Development Value: On
; Production Value: Off
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors
display_errors = On
...
; Log errors to specified file. PHP's default behavior is to leave this value
; empty.
; http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-log
; Example:
error_log = /var/log/php_errors.log

--------- End of php.ini -----

$ touch /var/log/php_errors.log
$ chmod 777 /var/log/php_errors.log

restart httpd

$ service httpd configtest
$ service httpd restart

open up the site using the public DNS in your web browser

give the site a good thorough functionality test and when you are happy with the site running as expected, all you need to do is switch the elastic IP from the current running site to the migrated site

open up the AWS dashboard in your web browser

on the left hand side choose ‘Elastic IPs’

highlight the Elastic IP and click ‘Disassociate Address’ -> ‘Yes, Disassociate’ (ensure you are disassociating from the correct instance id!)

that will release the IP from the current running instance, now we need to set the IP to the migrated server

click ‘Associate address’ – then choose the instance from the dropdown (its usually at the bottom)

then turn off the old instance server – thats all there is to it!!

 

Posted in amazon, aws, migration, svn | Tagged , , , | Leave a comment