Zend_Session SaveHandler for Memcache

Recently discovered that Zend_Session's DbTable SaveHandler is implemented in a way that is not very optimized for high performance, so, I've been investigating changing over to using Memcache for session management.

I found a decent pattern/class for changing the Zend_Session SaveHandler in my bootstrap from DbTable to Memcache here and added it into my web app.

In my bootstrap, I changed the SaveHandler like so:

FROM:

Zend_Session::setSaveHandler(new Zend_Session_SaveHandler_DbTable($config));

TO:

Zend_Session::setSaveHandler(new MyApp_Session_SaveHandler_Memcache(Zend_Registry::get("cache")));

So, my session init looks like this:

Zend_Loader::loadClass('MyApp_Session_SaveHandler_Memcache');
Zend_Session::setSaveHandler(new MyApp_Session_SaveHandler_Memcache(Zend_Registry::get("cache")));
Zend_Session::start();
// set up session space
$this->session = new Zend_Session_Namespace('MyApp');
Zend_Registry::set('session', $this->session);

As you can see, the class provided from that site integrates quickly with a simple loadClass and SaveHandler change in the bootstrap and it works in my local dev env without error (web app and memcache are on the same system).

I also tested my web app hosted in local dev env with a remote memcache server in PROD to see how it performs over the wire and it appears to also work okay.

However, in开发者_JAVA百科 my staging environment (which mimics production) my zend app is hosted on server1 and memcache on hosted on server2 and it seems that nearly every other request completely bombs out with specific error messages.

The error information I capture includes the message "session has already been started by session.auto-start or session_start()" and second/related indicates that Zend_Session::start() got a Connection Refused with an "Error #8 MemcachePool::get()" implicated on line 180 in the framework file ../Zend/Cache/Backend/Memcached.php.

I have confirmed that my php.ini has session.auto_start set to 0 and the only instance of Zend_Session::start() in my code is in my bootstrap. Also, I init my Cache, Db and Helpers before I init my Session (to make sure my Zend_Registry::get("cache") argument for instantiating my new SaveHandler is valid.

I found only about two valuable resources for how to successfully employ Memcache for Zend_Session and I have also reviewed ZF's Zend_Cache_Backend and Zend_Session "Advanced Usage" docs but I haven't been able to identify the source of why I get this error using Memcache or why it won't work consistently with a dedicated/remote memcache server.

• Does anyone understand this problem?
• Does anyone have experience with solving this problem?
• Does anyone have Memcache working in their ZF web app for session management in a way that they can recommend?

Please be sure to include any/all Zend_Session and/or Zend_Cache configurations you made or other trickeration or witchcraft you used to get this working.

Thanks!

---

This one just nearly exploded my head.

First, sorry for the book of a question...I wanted to paint a complete picture of the situation. Unfortunately, I missed a few key details which my wonderful coworker found.

So, once you install, most likely when you are just starting to test out the deamon, you will do this:

root# memcached -d -u nobody -m 512 127.0.0.1 -p 11211

This command will start up memcached, using 512MB on the localhost and the default port 11211.

Did you see what I did there? That means it's set to only process requests sent to the LOOPBACK network interface.

ugh

My problem was, I couldn't get my web app to work with a REMOTE memcached server.

So, when you actually want to fire up your memcached server to accept requests from remote systems, you execute something like the following:

root# memcached -d -u nobody -m 512 -l 192.168.0.101 -p 11211

This fixed my problem. This starts my memcached daemon, setting it to use 512MB bound to IP 192.168.0.101 and listening on the default port 11211.

Now, any requests SENT to that IP and Port will be accepted by the server and handled as you might expect.

Here's a networking doc reference...RTFM...a second time!