On Sat, Jul 18, 2009 at 7:14 AM, Daniel Kolbo<kolb0057@xxxxxxx> wrote: > Daniel Kolbo wrote: >> Eric Butera wrote: >>> On Thu, Jul 16, 2009 at 5:50 PM, Daniel Kolbo<kolb0057@xxxxxxx> wrote: >>>> Hello, >>>> >>>> Call me a dreamer...but I got to ask. >>>> >>>> Is there any software for helping speed up PHP by utilizing internal PHP >>>> caching? >>>> >>>> I am not talking about the external php cache/header control. Smarty >>>> caching doesn't give me the control I need either. >>>> >>>> I would like to cache to a finer level than page by page, but rather on >>>> a module by module basis. Each of my pages contains a subset of >>>> modules. The content of these modules changes based upon certain >>>> criteria (link, time, session data, but is sometimes static across the >>>> site). I would like to be able to cache individual "modules" >>>> (preferably based upon frequency and time to generate). >>>> >>>> I am trying to develop a way to do this, but I have to think a brighter >>>> mind has come before me and hopefully arrived at a solution. >>>> >>>> As always any help/thoughts are much appreciated, except for that one >>>> guy's comments (you all know who I am talking) ~ jk ;) >>>> >>>> Thanks, >>>> ` >>>> >>>> -- >>>> PHP General Mailing List (http://www.php.net/) >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> Have you actually profiled your code to see where the pain points are >>> vs saying 'module?' Are you also running an opcode cache? From there >>> you can use data, block, or full page caching. Finally you can figure >>> out if you want to store it in flat files or memory. I'd start by >>> knowing what is actually the slow part using Xdebug and nail a few >>> down. >>> >>> There is no end all solution. Some pages really don't have a lot >>> going on and are hardly updated so full page is fine. Others might >>> have something that is hard to generate on a sidebar, so block caching >>> would be more suitable for that. As previously mentioned, Zend_Cache >>> is up to the task. There is also a PEAR package called Cache_Lite >>> which would work to if you're interested in file based caching. >>> >> >> So dreams do come true... >> >> Thank you for the wonderful insight. I've been reading about the >> memcached and Xdebug and Zend_Cache. I've got lots to learn, but it is >> exactly the type of material i was trying to find. >> >> I am not currently running an opcode cache. I may be doing "premature >> optimization", but i want to design the entire system intelligently from >> the get go rather than having to rebuild later. you know 'work smarter >> not harder'.... >> >> Is it possible to run xdebug on a virtual host server on which i do not >> have shell access? I can modify php.ini via cgi, but I don't know if >> i'd be able to view the results of xdebug on the machine. Your opinion >> would be appreciated. >> >> Thanks so much, i feel like i've just been shown a whole new world. >> dK >> ` > > I still have to (fully) rtfm. But i was wondering if the following > scenario(s) is(are) possible. > > -Does memcached store the same data under different keys in the same spot? > > From my reading so far, i do not think so. > My understanding is that currently memcached goes like as follows: > key->key_hash->server->data_value > but this approach could conceivably store the same data_value under > different keys (thus consuming unneeded memory) > > What i'd like it to do is the following: > key->key_hash->server->data_hash->server->data_value > > That is, each key has the data_hash as its value. Then one uses this > data_hash as the new key which has the data_value as its value. > This way the only data that is replicated would be the relatively small > data_hash, but the (larger) data itself would not be replicated. > > This would allow for the user to use different keys to access the same > data. This would be needed when seemingly different keys happen to > share the same data, but would be too costly to recognize, predict, and > accommodate such associations > > This doubles the number of calls to the server, but could conceivable > save a great deal of memory for more cached objects. What would be even > slicker is if the programmer could use either approach within the same > script. For example, if the programmer new for (almost) certain that a > certain key would never have the same data signature as any other key, > she could then use the original method and save on the overhead of > storing key_hash to data_hashes pairs. > > Also, I really like the idea behind zend_cache that I can use memcache/d > as the backend. That's pretty modular! > > I have three direct questions: > 1) Is the above approach wise or have i violated some basic caching > principle? > > 2) Is the php memcache/memcached class extendable (so that I can > implement 1 above)? > > 3) If 2) is yes, can I use this extendable class as the backend for > zend_cache? > > Thanks, > dK > ` > > The fact you said you haven't used Xdebug or have an opcode cache means you're starting from the wrong end. I'm pretty sure using Zend_Cache with a flatfile backend would be more than adequate for your needs. As for your questions, if you think that is the way to use it that would benefit your program the best, then go ahead. I use caching inside method calls so that I can cache the result of my expensive method call and it is transparent to the rest of the app. -- http://www.ericbutera.us/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
