apache

Using memcached to share PHP sessions

Posted in apache, memcached, php on July 29th, 2010 by fseek – Be the first to comment

This tutorial explains how to install and configure memcached to share PHP sessions across multiple servers (all running CentOS).

One of my sites was outgrowing the cheap VPS server that we were paying for it. Instead of adding more memory/CPU, we decided to add more servers to the equation, sharing the load between them.

To do that, we started to use memcached. Memcached is very simple to use and install and is easy to integrate with PHP. Let’s get to work!

1- Installing memcached.

Memcached has some prebuilt packages for Ubuntu, but none that I could find the CentOS. Because of that, I had to install it manually from the source. It is simple as well, just follow these steps:

1.0 – Installing pre-requisites:

# yum install libevent-devel.i386
# yum install php-pecl-memcache.i386

1.1-Downloading:

# wget “http://memcached.googlecode.com/files/memcached-1.4.5.tar.gz”
# tar -zxvf memcached-1.4.5.tar.gz
# cd memcached-1.4.5

1.2-Compiling

# ./configure
# ./make && make test
# ./make install

1.3- Running it

# /usr/sbin/useradd memcached
# /usr/local/bin/memcached -d -u memcached

You see that we installed it at /usr/local/bin and created a restricted user for it. Now you should have memcached running. Just run “netstat -tanep” to check.

2- Configuring PHP

2.1 – Via php.ini

If you have access to the php.ini (like we had in one of our servers), just add the following to it:

session.save_handler = memcache
session.save_path=”tcp://serverA:11211″

After restarting Apache, PHP will use memcached that we installed on the “serverA”. That’s all.

2.2 – Via modifications in the php scripts

If you can’t modify your php.ini, add the following to your php scripts:

ini_set(’session.save_handler’, “memcache”);
ini_set(’session.save_path’, “tcp://serverA:11211″);

That’s it as well. If you are having problems with the sessions, make sure to use the same session name across servers:

ini_set(’session.cookie_domain’, “.domain.com”);
session_set_cookie_params(0, ‘/’, ‘.domain.com’);
session_name(“SESSIONX”);
session_start();

That’s it. Easy, no?

Worst PHP advice ever

Posted in apache, bad-advice, php on March 10th, 2010 by fseek – Be the first to comment

Last night I was browsing some books at the bookstore and glanced over at the following advice on a PHP+Flash book:

“To improve performance disable Apache access and error logging.

 
A bit after, another performance suggestion:

“To improve performance, minimize the ammount of error handling routines“.

Seriously? Are they kidding me? What’s next? Do not sanitize user input to improve performance?Unfortunately I can’t remember the book name, since I threw it far away and ran back home.

*have you read this book? Remember the name? If I can’t figure it out soon, I will go to the bookstore today again just to put them on shame ;)

htaccess to redirect your feeds to Feedburner

Posted in apache, tips, wordpress on March 3rd, 2010 by fseek – Be the first to comment

How to redirect your feeds to Feedburner without any plugin

Using Wordpress 2.9, I tried a few plugins to redirect all my feeds to feedburner, but Google Reader would still add the local feed automatically. The only solution that worked was from:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(feed|wp-atom|wp-feed|wp-rss|wp-rdf|wp-commentsrss)(.+)\ HTTP/ [NC,OR]
RewriteCond %{QUERY_STRING} ^feed [NC]
RewriteCond %{HTTP_USER_AGENT} !^(FeedBurner|FeedValidator) [NC]
RewriteRule .* http://feeds.feedburner/fseekme [R=307,L]
RewriteRule ^comments/?.*$ http://feeds.feedburner.com/fseekmecomments [L,R=302]

So, if you have the pretty URLs, just add the above (in bold) to your .htaccess file. Simple and easy!

Improving Apache performance by cleaning up its configuration

Posted in apache, guide, tunning on February 16th, 2010 by fseek – 3 Comments

Simple steps to improve Apache performance by cleaning up unused modules.

Apache is the most used web server on Linux systems and it has lots of features. By default, it generally comes with many of these features enabled, but if you don’t need them, why waste memory, cpu and at the end performance?

Let’s tune it a bit!

Default Apache

With the default Apache installation (on CentOS), it generally uses this ammount of memory:

# top |grep httpd
apache 3682 0.0 6.7 37408 24836 ? S Feb13 1:30 /usr/sbin/httpd

So around 37m for the worker processes. I also did a simple test with “ab” (Apache benchmark) to see how many requests per second it can take:

# ab -n 500 http://fseek.me/
..
Requests per second: 2.31 [#/sec] (mean)
..

So about 2.32 requests per second (I re-did this time a few times to get an average).

Cleaning up the configuration

I went to the Apache configuration (/etc/httpd/conf/httpd.conf) and disabled the modules that I was sure I wouldn’t use:

#LoadModule authn_dbm_module modules/mod_authn_dbm.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule speling_module modules/mod_speling.so
#LoadModule userdir_module modules/mod_userdir.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule cgi_module modules/mod_cgi.so

So I commented the proxy modules, cgi, ldap, etc.

Apache after the cleanup

After the cleanup (and restarting Apache), lets see how much memory it is using:

# top |grep httpd
apache 15715 0.8 4.4 29900 16588 ? S 15:24 0:00 /usr/sbin/httpd

So it went down from 37m to 29m of memory usage. If you are in a VPS (or slow box), that can really help performance. So, in addition to the memory usage reduction, let’s see if it improved the performance for our end users (average number of requests per second)

# ab -n 500 http://fseek.me/
..
Requests per second: 2.93 [#/sec] (mean)
..

That’s a good improvement too! From 2.32 requests per second, we increased to almost 3 per second (using ab, non-concurrent). The average time to complete the request also dropped from 429ms to 410ms…

It may look not much, but for such a simple change, why not do it?