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 un

Answer 1

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 2

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 3

While PHP can provide a lot of dynamic features for various data types, these operations arn't magical and the data is still stored as basic native datatypes within whats called a zval which is technically a complex hashtable within the native zend api. Like any other datatype in any language, each zval will only exist for a finite period. For PHP, this period is (at max) the period of handling a HTTP request. Under any situation, to make this data last longer than a single request, it must be converted from the original zval into some other form of and then stored in some way (this includes complex types such as PHP objects as well as basic types such as ints). This will always require re-initializing each zval, and then converting the data back from the stored form back into various PHP datatypes within the zval. Some storage formats such as BSON will be faster than PHP serialized strings, but (at least as of now) this will not provide much of a noticed performance jump as it is nowhere close to the performance of maintaining the original zval across multiple requests. You will still have to serialize this data in some way, go through the time of storing it, then fetching it, and then unserializing it. There are no real solutions for this at this time.

Note that PHP can be said to have three different scopes: the SAPI, which initiates and ultimately handles all state within each request; extensions, that are initiated before each request event is started; and then script scope which is initiated by each request. All PHP vars are initiated within the script scope, but can be accessed by both extensions and the SAPI. But the only scope that can exist beyond each single request is the SAPI. In other words, a PHP object can only be maintained across multiple requests within the SAPI (an extension cannot help with this problem at this time), therefor only a custom SAPI is able to maintain zvals across requests.

Answer 4

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.

Answer 5

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 6

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