Let’s assume you have PECL/Memcached up and running and want to use it as a session handler. I’ll talk below about why you’d want to do this (and why not) and how to get there.

Is storing sessions with Memcached a good idea?

As usual: it depends.
Regular file-based session storage is reliable and reasonably fast. It has its drawbacks though, especially when you want to scale: First of all, if you have several servers behind a load balancer, you need to make sure that a visitor always gets the same session if he is assigned to another server in-between. This is difficult if sessions are stored locally on each server. Also, a LOT of these tiny session files can pile up fast on your server, which makes server backups more difficult. Also, when you’re on a cheap cloud server, file I/O speed might not be optimal. So you start thinking about a RAM-based solution. One way to do this would be a tmpfs partition to store session files in memory. But remember, you still need a central place to store sessions. In comes Memcached.
Memcached operates in-memory only, and can be run on one or more central servers. Great, right? Yes and no. Memcached is not a database, but an LRU (“least-recently-used”) cache with a fixed size. If there is not enough room, the oldest items will be removed. If we use it for session storage, some people might be logged out randomly. Duh. So, if you want to use Memcached, you have to weigh its advantages and drawbacks. It’s certainly not a good option if you have important sessions (like shopping carts) that you cannot afford to lose. On the other hand, if it’s OK to lose a session once in a while, Memcached might be a good solution for you. It’s very fast and easy to set up, and it is supported as a session handler by PHP out of the box. You can mitigate the risk by assigning enough RAM, and by adding a “remember me” feature (if it’s not a security concern, depending on the type of your site). If you use a custom session handler, you can even use Memcached purely as a caching front-end for a database session store and get the best of both worlds.

How to set up Memcached as PHP session handler

There are two ways to use Memcached as your session handler: if you have no special needs, you can simply set some PHP ini options and you’re done. This was good enough in my situation and I’ll describe this solution here. If you want to use advanced options, like using persistent connections or using a combined Memcached/MySQL solution, you will need to use a custom session handler (not described here).

The easy way: set PHP ini options

As PHP comes with support for Memcached as session storage baked in, you only need to set two options and you’re good to go. You can either set these in your php.ini file, or at run-time in your application.
; either put this in php.ini
; replace or comment out the existing two options
session.save_handler = memcached
; change server:port to fit your needs
session.save_path="127.0.0.1:11211"
# or, include this in your application startup code
ini_set('session.save_handler', 'memcached');
ini_set('session.save_path', '127.0.0.1:11211');

Note: There are a few gotchas here, and this is actually what made me write this post. Most other blog posts about this topic use PECL/Memcache, not PECL/Memcached. Both have a different API and different options. If you’re using PECL/Memcached (like me), make sure to include the “d” in the handler name (“memcached”). Also, the save path must NOT include the protocol (just server IP and port). You CAN specify a comma-separated list of servers, but you CANNOT specify options here, like you can with PECL/Memcache. If you need special options, you must use a custom session handler, as mentioned above.

That’s it, we’re done! Now go ahead, restart Apache, and test your shiny new Memcached sessions.

Memcache, Memcached, what’s with the name?

There are two parts to this equation: a server component and a PHP client component. You will need both. For the PHP client, there are two options, one of which even shares the name with the server component, which has caused a good deal of confusion.

Installing and setting up the Memcached server

You’ll need to install the Memcached server component first to be able to store and read values. Fortunately, this is the easy part: install package, configure and start server, add firewall rule to secure server, done.

Installation

Memcached is available as a ready-made package in my favorite repository, Remi, so we can install it with:

yum --enablerepo=remi install memcached

This should hopefully proceed without any problems. If you don’t have the Remi repository, you should first add it to your system, or use the repo of your choice.

Configuration

Next we need to edit the server’s configuration, start it and add it to the system start configuration. As far as I see it, you have two options here: either use the provided start script from the RPM, or add your own. You can set several parameters, like the IP and port that the service runs on, the user, and the amount of memory assigned (keep in mind that this is a fixed value).
# Option 1: edit and use the RPM start script
#adapt options here, like memory available
vi /etc/init.d/memcached
# start service
/etc/init.d/memcached start
# add to system boot config
chkconfig memcached on
# Option 2: start server manually and add custom start command to /etc/rc.local
# start server as daemon
/usr/bin/memcached -d -m 1024 -u httpd -l 127.0.0.1
# next, add the above command to /etc/rc.local to make it run at boot-time

A word about the parameters shown above:
-d start as daemon
-u user name for Memcached (adapt to your needs)
-m amount of memory assigned, in MB
-l (this is an L) IP address to listen on

Making it more secure

I’ll assume you will use your Memcache server only locally. It’s a good idea to add an IpTables rule to block all outside requests to this server. Add a line like this to your IpTables config (I won’t show this in detail here):
-A INPUT -p tcp --dport 11211 -j ACCEPT
If you want to set up a dedicated Memcached server and access it from another server, you will have to change the above accordingly.

Testing your Memcached server

Let’s test our new server a bit. I’ll show you some tools with output from my test server below:
# Is the service running?
root@D4D-TEST01 ~: netstat -tap | grep memcached
tcp 0 0 *:11211 *:* LISTEN 29441/memcached
tcp 0 0 *:11211 *:* LISTEN 29441/memcached
# see some stats with memcached-tool (installed along with RPM):
root@D4D-TEST01 ~: memcached-tool 127.0.0.1:11211 stats
#127.0.0.1:11211 Field Value
accepting_conns 1
auth_cmds 0
auth_errors 0
bytes 1867
bytes_read 81117
bytes_written 54550
[... etc]

Let’s connect with Telnet and set and get a value. You can set values with “set [keyname] [flag] [expirytime] [bytes]” and get values with “get “. If you set a value, you specify the keyname and the options first, press Enter, and then specify the value on the next line. You can read more about these commands here for example.

root@D4D-TEST01 ~: telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
set mykey 0 900 6
mydata
STORED
get mykey
VALUE mykey 0 6
mydata
END

This is a bit clumsy of course, and what we really want is to set values from PHP. Time to install the PHP client component.

Again: Memcache, Memcached – what’s up?

This is where the confusion starts: there are two PHP client libraries available (both in PECL): one is called “Memcache” (or PECL/Memcache) and one is called “Memcached” (or PECL/Memcached). Yep, the second one is named exactly like the server. For a comparison, see for example here and here. The short of it: PECL/Memcache is older, less actively developed, and more widely used. PECL/Memcached relies on the libmemcached library, is newer and has more features. Most blog posts you’ll find are about PECL/Memcache, and that can be a bit misleading if you want to start out with PECL/Memcached.
After weighing my options, I decided to go with PECL/Memcached, and I’ll show you how to get it below.

Installing PECL/Memcached

If you just want the current stable version, get it from a suitable RPM. You will need libmemcached, too.

yum --enablerepo=remi install libmemcached
yum --enablerepo=remi install php5-memcached

After reading about some bugs in that version, I decided to use the current beta though, so I had to get it from PECL, which proved to be a bit more challenging. To make a long story short, you will definitely need zlib and libmemcached first, and probably their development libs as well (plus PECL of course):
yum --enablerepo=remi install zlib zlib-devel
yum --enablerepo=remi install libmemcached libmemcached-devel
pecl install memcached-beta

That should do the trick. You might have to add
extension=memcached.so

to your php.ini, if it’s not there already. If you call up phpinfo() (after restarting Apache), it should look like this:

Testing, again

So let’s test our new client with a little PHP script:
<?php
$mc = new Memcached();
$mc->addServer('localhost', 11211);
$mc->set('testkey', 'Hello there');
echo $mc->get('testkey');

Keep in mind that the APIs for Memcache and Memcached are very different, so most examples you see on the net won’t work for PECL/Memcached. The correct version of the documentation (as opposed to the one for Memcache) is here.
If you want to use persistent connections, make sure that you only add a server when none is defined yet, lest you end up with hundreds of them:
if (!count($mc->getServerList()))
$mc->addServer("localhost", 11211);

That’s about it. You now have a working Memcached setup and can use it for your caching purposes.

You can also use Memcached to store your sessions, but that will be covered in my next post.

The video below makes me feel a little nostalgic…

spreepark berlin rewinded from kriz mental on Vimeo.

I’d like to share a few tips here on how to optimize your error logging when using Zend Framework (“ZF”), one of the most established PHP frameworks available. I assume that you already know to use this framework. .

Basic Strategies – Filtering And Fingerprinting

When we released the e-fellows.net Community (a closed social network for holders of the e-fellows.net scholarship), logging was a straight-forward affair: all errors were logged to a file. It quickly became apparent that this was not good enough: often, critical errors went undetected for days, because nobody bothered to look into the logs regularly.

So we implemented a priority-based filtering strategy: errors and log messages up to a certain log priority are logged into various files, as before. Additionally, more important errors are sent out via email to a workflow folder that is checked regularly. The most critical errors are emailed directly to all members of technical staff.

All was fine for a while until we realized that sometimes, for example after a release, the same error occurs repeatedly on every page, leading to thousands of emails that flood your inbox within minutes. That’s why we came up with the idea of assigning each log message a unique fingerprint which is stored in the database. Each time a message is to be logged, its fingerprint is first checked in the database. If it has already been logged within the last, say, 24 hours, it is discarded.

The last step was to setup log-rotating on the server, i.e. older logs are automatically archived and then deleted after a certain time (but that’s beyond the scope of this article).

Next I’m going to show you how to setup log filtering with the Zend Framework. Message fingerprinting
will be covered later in the article.

Log Setup

First, we define a few logs and a simple log-format:
//config.php
$loggers = array('framework','database','import','admin','login','minifeed',
'signoff','notification','cron','newsletter','mail','upload',
'application','pdf');
Zend_Registry::set('loggers', $loggers);
$logFormat = date('r') . ', "%message%" (%priorityName%)' . PHP_EOL;
$simpleFormatter = new Zend_Log_Formatter_Simple($logFormat);

Next, for each log, we define a file-based log writer that writes all messages above a certain priority to a specified file. Messages with a lower priority (i.e. debug messages) are discarded. If we really want to see those debug messages (like for, uhm, debugging), we just change the corresponding config setting. Message priorities are actually arbitrary (though you have to choose one of the pre-determined values). It’s up to you to define what priority an error should have and what that means to you.

foreach ($loggers as $aLogger) {
$loglevel = $config->log->level;
$class = new ReflectionClass('Zend_Log');
$priorities = array_flip($class->getConstants());
$loglevel = array_search($loglevel, $priorities);
$fileFilter = new Zend_Log_Filter_Priority($loglevel, '<=');
$fileWriter = new Zend_Log_Writer_Stream(APP_LOG_PATH . '/' . $aLogger . '.log');
$fileWriter->setFormatter($simpleFormatter);
$fileWriter->addFilter($fileFilter);

(Note: In the code above, we first determine all available log levels via reflection. Then we define that all messages with a priority below a certain threshold get logged (all others will be discarded). That’s because in the Zend Framework (like with UNIX system logs), a more severe error is mapped to a priority with a lower numeric value. In this article, I describe things the other way round because I find it more intuitive that way.)

Next, we set up a log writer that emails log messages with priority “ERR” or higher. It includes another threshold for sending critical messages to another mail address, but we’ll come to that later.
$mailWriter = new Default_Helpers_EmailLogWriter();
$mailFilter = new Zend_Log_Filter_Priority(Zend_Log::ERR);
$mailWriter->addFilter($mailFilter);
$mailWriter->setFormatter($simpleFormatter);

Lastly, we instantiate a logger object, attach the two writers to it and save it in a registry for easier access:
$logger = new Zend_Log();
$logger->addWriter($fileWriter);
$logger->addWriter($mailWriter);
Zend_Registry::set('log' . ucfirst($aLogger), $logger);
}

Log Usage

Logging an error is straight-forward and done the standard Zend Framework way. In client code, errors are logged like this:
Zend_Registry::get('logDatabase')->err(__METHOD__ . ' - error getting proper
sysid from oracle');
The developer doesn’t need to know how log messages are handled internally. We just get a log from the registry and write an entry with a certain priority. (For exceptions, we use another method which includes a stack trace.)

This would result in a log message like the following, which contains information about the date, method name and the actual message:
Fri, 22 May 2009 14:19:57 +0200, Default_Helpers_Database::getNextSysId() -
"error getting proper sysid from oracle" (ERR)

Based on its high priority, this message would get logged to file and be sent out via email, too.

Logging to email

In the code above, you may have noticed a reference to the class Default_Helpers_EmailLogWriter, which extends the abstract log writer base class provided by ZF and implements the _write() method:
class Default_Helpers_EmailLogWriter extends Zend_Log_Writer_Abstract
{
protected function _write($event)
{
$errorHandler = new Default_Models_ErrorHash();
if (false === $errorHandler->isErrorAlreadyLogged($event['message'])) {
$mail = new Default_Helpers_Mail();
$msg = $this->_formatter->format($event);
if ($event['priority'] < Zend_Log::ERR) {
$mail->sendCriticalError("System Message: A Critical Error Ocurred!", $msg);
} else {
$mail->sendToAdmin("System Message: An Error Ocurred!", $msg);
}
}
}
}

The first two lines of the _write method check whether the method was logged before (see below). If not, we instantiate a mail helper and send the log message via email. Remember, messages only get this far if their priority is at least “ERR”. If the error is even more critical, it is not sent to the standard address, but directly to the admin team’s inboxes, to make sure it gets handled promptly.

Logging Messages Only Once A Day

In order to avoid sending the same email repeatedly, we create an md5 hash for each message and store this hash value, or “fingerprint”, in the database (remember that the message contains additional info like the method the error occurred in). If this message was already logged within the last 24 hours (or any other interval we have configured), we discard it. This is determined with the help of the Default_Models_ErrorHash class:

class Default_Models_ErrorHash extends Default_Models_Database
{
protected $_name = 'Errorhash';
protected $_primary = 'errorhash';

This class only contains one method which checks whether an error is already “known”. First we delete all hashes that are older than the configured interval. Then we look up the message’s fingerprint in the database. If it is found in the database (i.e. it was already logged within the last 24 hours), we simply return true. Otherwise, the hash will be inserted into the database.
public function isErrorAlreadyLogged($errorMsg)
{
$db = $this->getAdapter();
$where = $db->quoteInto('created <= DATE_SUB(NOW(), INTERVAL ? HOUR)',
Zend_Registry::get('config')->log->resendErrorMailAfter);
$db->delete($this->_name, $where);
if (false === empty($errorMsg)) {
$md5 = md5($errorMsg);
$query = 'SELECT COUNT(*) FROM '.$this->_name.' WHERE errorhash=?';
if($db->fetchOne($query, $md5)) {
return true;
} else {
$db->insert($this->_name, array('errorhash' => $md5));
}
}
return false;
}
}

The Errorhash table looks like this:
CREATE TABLE `Errorhash` (
`errorhash` char(32) collate utf8_unicode_ci NOT NULL,
`created` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY (`errorhash`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Wrap-up

There you have it: I have shown you how to filter log messages with the Zend framework based on their priority, and how to avoid getting flooded with log emails. Both strategies help to make much better sense of your error logs.

Have you found other ways to optimize your error logs? If so, please share them below.

What held me back so long was the missing support for Google Browser Sync, which I’ve come to rely upon heavily, because it ensures a smooth transition between my various computers. Fortunately, something similar is emerging for FF3: Mozilla Weave. It’s still in early alpha and very buggy, but it looks promising.

I had signed up a few days ago, but I had forgotten my encryption passphrase, but fortunately I was able to delete my Weave profile data with the help of this tip from Lars Tackmann.

There was still the problem that the Mozilla Weave server is very slow and often overloaded. Then I learned that you can host the service elsewhere. Good thing that I just got my own server from slicehost.com!

Using Remco Bressers tutorial, I had a Weave account running on my own server in no time, and it performs much better, too.

I’ll cover questions like these:

• Background and characteristics of XML
• Reasons for using XML in the software translation industry
• XML as a family of technologies (XSL etc.)
• XML standards for the L10N industry (XLIFF, TMX etc.)
• Tool support (especially TRADOS 7)

In the next issue of “MDÜ” (the quarterly magazine of the German translators industry association BDÜ), I’ll publish an article on the same subject.

Their old site had several severe problems. Due to a few poor design choices, it was hard for users to navigate. Even worse, the site was Flash based and could only be updated if you knew your way in Flash. If you are a non-technical club owner and need to publish events regularly, this can become a huge hindrance indeed.