NYCPHP Meetup

[Tom Melendez]

On Fri, Jul 18, 2008 at 5:51 AM, Patrick May <patrick at hexane.org> wrote:
> Tom,
>
>> First thoughts: why not Zend or Pear cache libraries?
>>
>>
>> http://framework.zend.com/manual/en/zend.cache.theory.html#zend.cache.factory
>> http://pear.php.net/package/Cache_Lite
>> http://pear.php.net/package/Cache
>>
>> The pear packages are looking for maintainers - perhaps you could roll
>> your work into that?
>
> Thanks, these were the sorts of libraries I wanted to check for reference.
>
>>
>> So, what is your goal with this caching library?  FE caching can be
>> fixed with more boxes or a squid layer.  Datasources can be harder to
>> cache but will be much more valuable when you try to scale.
>
> My experience is that the broader the cache the less effective.  Caches can
> make sites appear un-responsive or oddly buggy to users.  I've done reverse
> proxy caching with Squid, but it's painting with an extremely large brush.
> You can't target *part* of a response for caching.
>

Agreed.  Multiple layers of caching are also can be a pain to testing
and debug.  But even if I only I only served from that cache 10% of
the time, I'd still want it there.

> I also don't believe in "more boxes" all the time.  While an important part
> of scaling is adding more resources, it's also important not to waste the
> resources you have.  For example, you can cache the datasource.... or the
> result set.  If the two have the same effectiveness, then I'd rather cache
> the result set because that extends the per-box capacity.
>
Yes, as long your data is tied to only one view.  My experience has
been that performance issues stem from the datasource rather than the
FE rendering.  Don't get me wrong, I used local, file based cache as
well, but I cache the datasource separately.  And for FE cache, you of
course don't want to cache the view (or page module or widget or
whatever) if your datasource fails.

> If my application is failing to meet performance expectations, I like to
> have on hand some caching tools to see if I can rescue it.  And that would
> be the purpose of this library.
>
Yes, this would be the quickest way to breath life into a fledgling or
over-taxed application.  Wouldn't require too much work and can handle
user/session specific page modules.

Tom
http://www.liphp.org