tag:blogger.com,1999:blog-1549959395955666242.post4007185910688258153..comments2012-08-27T21:15:43.118+01:00Comments on VITO'S THEREFORE: Session-based object instantiation with memcachedVitohttp://www.blogger.com/profile/04291961803377428688noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1549959395955666242.post-75625948082866452422009-03-10T12:15:00.000+00:002009-03-10T12:15:00.000+00:00I'm actually working on a very similar idea at...I'm actually working on a very similar idea at the moment. Only I skip the session part and save/restore directly from memcached. I agree with others here in that this should not be used blindly with every object. I use this sort of system mainly for business domain objects, because often these objects hit the database to fetch business-specific data.<BR/><BR/>For example, I use this for a Customer object. This type of object will often have to select a row from a DB associated with a Customer ID. This happens on every request. But by caching the object in memcached, I save that DB call. Care must be taken when modifying the data and invalidating the cached object.<BR/><BR/>For a set of Customers, I only need to hold the set of IDs in a list, as opposed to querying all data for all customers and holding it in a multi-dimensional array.<BR/><BR/>I also use magic methods (__get, __set) to access object fields so I can intercept these requests and use lazy-loading. That way, if I want $customer->orders, I won't query the DB for orders upon instantiation. Oh, and each subsequent request for that customer's orders is pulled from cache, even across requests.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-10290272629212822522009-03-09T22:42:00.000+00:002009-03-09T22:42:00.000+00:00Thanks for all the feedback! Some further thoughts...Thanks for all the feedback! Some further thoughts:<BR/><BR/>Deserialization from memcached involves memory, while new object instantiation may require file access (barring opcode caches).<BR/>Opcode caches are great, but we need further session specificity if we want to give user with long logins and plenty of action priority resource.Vitohttps://www.blogger.com/profile/04291961803377428688noreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-80759423968348090392009-03-09T21:05:00.000+00:002009-03-09T21:05:00.000+00:00Where objects have significant cost for initializa...Where objects have significant cost for initialization (lotta function calls/parsing files/DB queries), this is a good thing. E.g. a permissions/roles object for a user (store in session), or an app config object that has to parse ini/yaml/xml files (store serialized, but not in sessions!).<BR/><BR/>Where this won't get you anything is simple objects with low construction cost (e.g. controller objects). Remember a memcache get doesn't do any magic: it just pulls a string and calls unserialize(). I.e. PHP still has to execute the bytecode to define the class and functions in your app, and this may take quite a bit of the request time.<BR/><BR/>Guess I'm saying, don't throw out the "new" operator. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-17710190714249475982009-03-09T18:43:00.000+00:002009-03-09T18:43:00.000+00:00This seems like an interesting concept, but I worr...This seems like an interesting concept, but I worry that it sacrifices too much in the way of loose coupling if you're using this throughout an entire framework. If you're working in a framework like Zend, you lose a lot of what makes it unique and powerful if all of your classes depend on a SessionObjectFactory class to be instantiated.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-23284408030756231052009-03-09T15:34:00.000+00:002009-03-09T15:34:00.000+00:00Data in session gets serialized and torn down with...Data in session gets serialized and torn down with the PHP process just as much as any other object. Unless your object instantiation has more overhead than PHP object deserialization (which in itself, creates a "new" instance anyway), then this is just going to make it worse. <BR/><BR/>Serializing the object into memcached is much cleaner and won't pollute session data with things that don't naturally belong in it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-89457868146728642442009-03-09T10:06:00.000+00:002009-03-09T10:06:00.000+00:00Have you actually come across performance problems...Have you actually come across performance problems with the default behaviour, or do you just have a hunch it must be bad so you'll "optimise" it out just in case?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-78701831716543107432009-03-09T08:52:00.000+00:002009-03-09T08:52:00.000+00:00The question is: What do you want to achieve?Your ...The question is: What do you want to achieve?<BR/><BR/>Your code implements the singleton pattern with session persistence. If this is what you need then fine.<BR/><BR/>But I understand your post to be more aimed at performance considerations, and until proven otherwise, I doubt you'll gain much. Each object you either want to instantiate or revive from persistent memory has it's class code to be parsed before.<BR/><BR/>If that's your problem because your code base is getting bigger, then I'd rather try opcode caches, just like APC.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1549959395955666242.post-71926094280628375662009-03-09T04:16:00.000+00:002009-03-09T04:16:00.000+00:00Sessions do not store "objects" they store a seria...Sessions do not store "objects" they store a serialized string representing that object..<BR/><BR/>It still has to be "created" and if that object held any resources they are no longer valid and have to be redone.<BR/><BR/>Complex objects will still be complex, will still have overhead to as they are created from the serialized data.<BR/><BR/>But in the end only objects that store data pulled from the database or other "slow" sources and therefore can skip talking to those sources will benefit from such things.<BR/><BR/>If you used this method for all factory methods it would provide unneeded overhead and a overload of useless default properties and data in your memcacheAnonymousnoreply@blogger.com