2

What I have been able to grasp from reading the source and documentation from several PHP frameworks is that they generally don't persist, except for what you personally cache or throw into a $_SESSION var. Why is this? It seems a waste to essentially initialize the framework for every single request, would it not be better to at least serialize and store some core objects and variables to save processing and time?

At first I thought this was rather subjective and avoided asking, but everything I've read doesn't really speak about it at all, so there must be something obvious I'm missing.

The only real mention/discussion I've found of this is here which doesn't directly answer my question and some of which goes over my head a little.

Edit for Clarification: I am not asking about the inner workings of PHP, I know how persistence works (ie won't persist unless you make it through caching or session vars), I am asking why PHP frameworks don't do this for their core objects. Again it seems subjective to me, but as almost nothing I've read mentions it, and it seems to be fairly standard practice, I'd like to know what I'm missing.

Community
  • 1
  • 1
asdf
  • 357
  • 2
  • 11
  • Nothing persists in PHP unless you explicitly ask it to persist in `$_SESSION` or via another caching mechanism. – Michael Berkowski Apr 03 '12 at 18:20
  • I realize that, what I am asking is why don't frameworks use those mechanisms to persist core objects that are generally instantiated during the initialization of the framework? – asdf Apr 03 '12 at 18:23

2 Answers2

3

Memory:

Most frameworks don't store these core mechanisms in $_SESSION due to memory concerns. Frameworks often generate variables / objects that can contain several megabytes of information. That may not sound like a lot, but scale that to a few thousand users and you've got a problem.

Data "Freshness"

The second issue with shoving framework components into memory is that they can become out of date very quickly. Instead of pulling an object out of memory, checking to see if it's outdated and then recreating it (if it's indeed outdated) is less efficient (most of the time) than just recreating it with every request.

I hope this clarifies things.

Levi Hackwith
  • 9,232
  • 18
  • 64
  • 115
  • What sort of objects or data (or in what context) would it be more efficient for the objects/data to persist? – asdf Apr 05 '12 at 18:24
  • 1
    That really depends. Usually, ID's are what's mainly stored in session (user ID, for example). The goal is to keep the size of the data as small as possible, so small pieces of data that can be used to retrieve objects is usually what's stored as opposed to entire database models or objects themselves. – Levi Hackwith Apr 06 '12 at 21:03
  • And how about caching objects (like for example saving a serialized version of a large object, say in a text file or something), in what context would that generally be done? – asdf Apr 07 '12 at 16:34
  • 1
    You would serialize an object and store it in memory when you had a lot of data you wanted to access frequently but not have it be a bunch of memory values. For example, if you had a class that represented a user and all of its properties: username, password, preferences, etc., you would serialize and instance of the User class and store it in memory. This would make it easier to work with across pages but you would eventually run into the "data freshness" issue I mentioned earlier. – Levi Hackwith Apr 07 '12 at 16:37
0

If you want data to persist between server requests then you need to use cookies/sessions or store your data in a database. This is just the way that it works. PHP cannot store data in itself for use between server requests.

Some frameworks may store core objects in a database or to a local file on disk, but it would depend on the framework.

Jake
  • 1,135
  • 1
  • 12
  • 26