Re: Internal PHP caching methodology

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
`


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux