Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am writing my own PHP framework (...waits for the groans to subside) for the purpose of learning (best practices, design principals etc.) as I'm entirely self-taught and consequently there are gaps in my knowledge.

I understand that most mainstream frameworks incorporate some form of caching system, which I'm guessing is for keeping regularly used classes and/or other files close by for fast loading (right?).

Ideally I envisage a system that is somewhat self monitoring and self managing in that it tracks class/file usage, memory limits and request processing performance, removing items from cache automatically when no longer needed or increasing the cache size when performance drops too low etc. (even some form of basic garbage collection is better than nothing, right?).

So my questions are:

  • Firstly: Have I understood everything correctly so far?

  • How important is it to implement this kind of system over regular include/require methods?

  • How can I determine memory usage and other system performance metrics?

  • To cache classes do I have to use the '_sleep()' and '_wakeup()' magic methods?

  • I also gather that to be stored a class has to be serialized. Should I use a $_SESSION variable, a temporary DB table or some kind of flat-file / SQLite DB as the cache?

Thanks for any and all help / suggestions.

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

I understand that most mainstream frameworks incorporate some form of caching system, which I'm guessing is for keeping regularly used classes and/or other files close by for fast loading (right?).

It's a bit more complicated than that; the frameworks typically provide mechanisms for caching an entire view's results. E.g. you may have a (sub) view which provides the top 5 articles. If you let the framework know that this view must only be re-rendered every 5 minutes, it will try to cache it on the first request. Subsequent requests will be given the same pre-generated response, until the five minutes has elapsed. Typically you also have ways of specifying whether this behaviour is global, or per-session, which URL parameters define a unique request which needs to be cached, etc. This is an optimisation, and can provide large benefits in many cases. Symfony 2's documentation has a very good explanation of the principles.

You may also choose to cache things at a lower level. E.g. retrieving the list of countries from the DB for each request is a waste of resources, and can be avoided by caching that list on the first request. This may or may not be a core part of a framework, but even in this case, you shouldn't roll your own, as others have pointed out. In general, the previous mode of caching seems to favoured, since it prevents even the view logic from being run, a greater saving.

In terms of how necessary any of this is; it really depends on your situation. In my experience, unless you're expecting large numbers of users (say, more than a few dozen on your site at the same time), you don't need caching. A site like StackOverflow, on the other hand, would not be able to function without a very well thought out caching strategy.

share|improve this answer
    
I hadn't thought of caching being used like this, but it makes sense. So rather than caching framework classes/files the performance benefit comes from caching results sets and compiled view output renders? –  Chris Jul 25 '12 at 14:42
    
@Chris - well, caching in general is implemented in many ways. E.g. APC caches things on a bytecode level. Entities are often cached in RAM to prevent computation and fetching from slower devices. The view-level caching makes a lot of sense in MVC frameworks, since it can prevent a LOT of work. Of course, you cache even before that - e.g. if you serve up your own JS files, put a version # in it, and configure your server to tell clients not to download it again for a year. That alone will prevent many requests. –  Daniel B Jul 25 '12 at 14:47
    
Thanks Daniel, I guess I'll do some more research before deciding what to implement. Like I said it's a learning exercise as much as anything so I'll see what I think is worthwhile. –  Chris Jul 25 '12 at 14:52
    
Actually as you mention it I was planning on using asset caching and long expires for javascript and css etc. I also want to include optimisation methods such as concatenation and compression, with support for style-sheets written in LESS/SASS. –  Chris Jul 25 '12 at 14:57
    
@Chris sounds good, glad I could help. –  Daniel B Jul 25 '12 at 14:59
add comment

From my experience, caching is necessary only when it is very slow to initialize some classes (for example they read system information which takes a long time to process).

For these problems you can use PHP's Memcache. I see absolutely no point in inventing another caching mechanism for PHP.

share|improve this answer
    
+1. Exactly. Only if your code doesn't match the original performance requirements, profile your code, find the bottleneck, and then optimize. –  MainMa Jul 25 '12 at 14:07
    
Thanks, I see your point. Is this likely to be a huge headache for little reward even as a learning exercise? –  Chris Jul 25 '12 at 14:40
    
Using Memcache is not that complicated and it's good to be known. So, for a learning exercise, it's a good candidate. Implementing something like Memcache on the other hand would probably be too much. –  Patkos Csaba Jul 25 '12 at 17:21
add comment

I wouldn't bother, as long as your execution time is not terribly slow. You can keep objects in the shared memory if you like, so no serialization is needed. This would probably also be the most elegant way.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.