Thứ Sáu, 22 tháng 4, 2011

Upgrading PHP and installing APC on CentOS 5 with Plesk


Every time I setup a new server, I find myself going through the same steps. Upgrade PHP to something greater than 5.2 (preferably, the latest stable version), install APC, and make sure it all works. It's always a pain, too, unless I follow the same basic steps, so I'm going to write them down here and hope that they don't change. Feel free to use these steps too. Remember, I'm running CentOS 5.2 Linux with Plesk, and I've already got PHP, MySQL and Yum installed.
Command Line Steps
Upgrading PHP:
wget -q -O - http://www.atomicorp.com/installers/atomic.sh | sh
yum update php
This enables the Atomicorp Yum repository, which includes a stable version of PHP 5.2. If a straight wget & sh seem scary, you can check out this page: Atomicorp Downloads.
At this point I restart apache, which is usually: service httpd restart. I then verify that PHP is at version 5.2 with:
php -v
The expected output is something like:
PHP 5.2.6 (cli) (built: May  2 2008 16:06:40) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
Now it's time for APC (see an explanation of why APC is a must-have on any PHP server at the end of this post):
Install Pear:
yum install php-pear
This allows me to access the PHP Extension and Application Repository, which has APC.
Install PHP Development Tools:
yum install php-devel
This allows me to compile PHP extensions, and never seems to be installed by default.
Install Apache HTTPD development tools:
yum install httpd-devel
This is necessary to setup APC under PHP 5.2.
Install APC:
pecl install apc
This should build the extension, unless something goes wrong.
Now, to configure APC there are two options: either edit php.ini, or add apc.ini to the php.d folder. Either way, I use the following:
extension = apc.so
apc.enabled = 1
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX
With the exception that sometimes I raise the apc.shm_size to a higher value. This value is the number of MB of shared memory to use for opcode caching, and on a bigger server with more RAM and more scripts to cache, I'm willing to allocate more.
Again, php.ini is usually located at /etc/php.ini and apc.ini would be a new file to place in the /etc/php.d/ folder. The important thing is to change one of these files, not both, or else you would be loading the extension twice.
Finally I restart apache again (service httpd restart) and verify that php -vreturns the same output. If I want to verify that apc is working, I locate apc.php on the server and then copy it to a web-accessible directory. Then I load that script in my browser, and if I can see pretty graphs, then it's working. Don't leave this file in a web-accessible directory, though; you wouldn't want others getting the information it has.
And that's it… at this point, I'm ready to develop whatever application I'm working on. Now, as for an explanation of why I insist on APC these days, as opposed to Xcache or Eaccelerator or, gasp, nothing at all:
You have got to use an opcode cacher with PHP. Otherwise, all your scripts have to compile every time they run, which takes a significant amount of time in comparison to whatever else your scripts do. As for which one you should use, APC is very stable and widely supported. I've noticed that APC is less likely to fail than the other cachers, which is really important when I am working on production sites. Anyway, just try it for yourself; install APC on a server that doesn't have any other caching methods, and you should notice a difference.
P.S. The following links were essential to putting these steps together:

Không có nhận xét nào:

Đăng nhận xét