Cache Object in PHP without using serialize

Question

I have a complex object that I create in a PHP script. I am looking for a way to store this object such that subsequent requests do not have to recreate it, or spend time unserializing and rebuilding it. Using xdebug I find that I spend half of the entire request time building this object. Even when I store the object explicitly in APC (or memcache), the time to unserialize it and load all of the classes takes almost as long as creating the object in the first place.

I do not know if it is possible to store and later load a "compiled" object in PHP. Is this possible? Are there other solutions?

I am not sure that this is possible, but I thought I should ask the community.

EDIT: The object is a binary tree, and used as a decision tree. The code is basically an API that is required to quickly return an answer from the tree. This all needs to perform at an ever increasing rate so I am trying to maximize the performance wherever possible.

Answer 1

NO, it is not possible to store a PHP object in a non-serialized form ; at least, not with the following caching solutions (I've tried these ones ; don't know about the other that might exist) :

• files
• memcached
• APC
• Database (yeap, you can think about caching things in DB ^^ Drupal does it by default, for instance )

If it takes that much time to unserialize your object, maybe it is really big ? Is there any way you could reduce it's size ?

For instance, meybe you have a big bunch of HTML code in that object ? If so, could it be stored in another cache entry ?
(serialization is "transforming some data to a string ; so, if you are already working with a string, you don't need to re-serialize it to store it in cache)

Or maybe it doesn't take much time to create it from scratch ? In this case, is caching really necessary ?

Answer 2

As far as I'm aware, it's not possible to cache objects in PHP without serializing. In general, however, caching mechanisms (APC, Memcache, etc) are really trying to remove the db connection(s) more than improve performance (and thereby decrease the overall DB strain). This is definitely how memcache, et al are employed with regards to Drupal. In other words, the caching mechanisms should allow you to scale, though they may not particularly improve performance.
Implementing a caching mechanism should allow you to more easily scale outward, even if the performance per machine is no better than before for a single connection. At a certain threshold, DB performance will degrade sharply, and the caching mechanisms should help alleviate that issue.

Answer 3

Maybe the solution is to not build a single, massive, expensive object.

Given that a PHP application pretty much starts from a clean slate on every page load, a solution that depends on a single, giant object is a poor fit to the language. Since you don't go into much detail about what your object is & what it does, I can't be certain, but I'd suspect you don't really need everything the object does on every page load. If that's the case, you might seriously consider splitting it into a number of smaller, simpler classes that you can instantiate as needed.

Answer 4

Look into the Igbinary PHP extension. It is a drop in replacement for serialize and unserialize and it may suit your needs.

It stores objects in a binary format instead of a string which decreases memory usage and also decreases the time to serialize and unserialize objects.

Although this does go through the process of unserializing an object, the binary format may increase performance enough to make this process reasonable for use in your application.

Answer 5

in this case a better option would be to write your own server.

it's easily doable in php - and you already have the code - but php may not be the first choice of most when it comes to writing servers.

• it may become the new bottleneck of your app (as php is not really multithreading-ready and requests are answered serially)
• not all hosters allow custom cli scripts
• if your decision tree changes, you have to notify your server to rebuild the tree

Answer 6

igBinary is a useful extension that may help you achieve a faster serialize/unserialize process. It replaces the standard serialization mechanism with a more clever, binary one. If you manage your own server and can install this, it's worth a try.

Answer 7

if possible on your platform write a simple daemon that loads the your tree at startup then answers requests over a socket. Your server process can fork and answer queries without recreating the tree. Writing a daemon is not trivial, but very well documented (at least for C). You should have no trouble translating this to PHP using the pcntl and posix extensions.