PHP Object Caching performance

Question

Is there difference between caching PHP objects on disk rather than not? If cached, objects would only be created once for ALL the site visitors, and if not, they will be created once for every visitor. Is there a performance difference for this or would I be wasting time doing this?

Basically, when it comes down to it, the main question is:

Multiple objects in memory, PER user (each user has his own set of instantiated objects)

VS

Single objects in cached in file for all users (all users use the same objects, for example, same error handler class, same template handler class, and same database handle class)

Answer 1

Unfortunately there is not right answer for this. The same solution for the same website on the same server can provide better performance or a lot worse. It really depends on too many factors (application, software, hardware, configuration, server load, etc).

The points to remember are: - the slowest part of a server is the hard drive. - object creation is WAY better than disk access.

=> Stay as far as possible from the HD and cache data in RAM if possible.

If you do not have performance issue, I would advice to do... nothing.

If you have performance issue: benchmark, benchmark, benchmark. (The only real way to find a better solution).

Interesting video on that topic: YouTube Scalability

Answer 2

Can be useful in certain cases, but comes with careful study of implications and after other kind of performance improvements (like DB queries, data structure, algorithms, etc.).

The query you cache should be constant (and limited in number) and the data, pretty static. To be effective (and worth it), your hard disk access needs to be far quicker than your DB query for that data.

I once used that by serializing cached objects in files, on relatively static content on a home page taking 200+ hits/s with a heavily loaded single-instance DB, with unavoidable queries (at my level). Gained about 40% performance on that home page.

Code -when developing that from scratch- is very quick and straightforward, with pile_put/get_contents and un/serialize. You can name your file after, say, the md5 checksum of your query.

Answer 3

To use these objects, each PHP script would have to deserialize them anyway. So it's definitely not for the sake of saving memory that you'd cache them on disk -- it won't save memory.

The reason to cache these objects is when it's too expensive to create the object. For an ordinary PHP object, this is not the case. But if the object represents the result of an costly database query, or information fetched from a remote web service, for instance, it could be beneficial to cache it locally.

Disk-based cache isn't necessarily a big win. If you're using PHP and concerned about performance, you must be running apps in an opcode-caching environment like APC or Zend Platform. These tools also provide caching you can use to save PHP objects in your application. Memcached is also a popular solution for a fast memory cache for application data.

Also keep in mind not all PHP objects can be serialized, so saving them in a cache, whether disk-based or in-memory, isn't possible for all data. Basically, if the object contains a reference to a PHP resource, you probably can't serialize it.

Answer 4

Having the objects cached in memory is usually better then on the disk:

http://code.google.com/p/php-object-cache/

However, benchmark for yourself and compare the results. Thats they only you can know for sure.

Answer 5

Is there difference between caching PHP objects on disk rather than not?

As with all performance tweaking, you should measure what you're doing instead of just blindly performing some voodoo rituals that you don't fully understand. When you save an object in $_SESSION, PHP will capture the objects state and generate a file from it (serialization). Upon the next request, PHP will then create a new object and re-populate it with this state. This process is much more expensive than just creating the object, since PHP will have to make disk I/O and then parse the serialized data. This has to happen both on read and write.

In general, PHP is designed as a shared-nothing architecture. This has its pros and its cons, but trying to somehow sidestep it, is usually not a very good idea.

Answer 6

I think you would be wasting time, unless the data is static and complex to generate.

Say you had an object representing an ACL (Access Control List) stating which user levels have permissions for certain resources.

Populating this ACL might take considerable time, especially if data comes from a database. The cached ACL could be instantiated much quicker.