NYCPHP Meetup

[Patrick May]

bzcoder,

I hear your point that using a framework, one should be aware of the various
framework-specific options for improving performance.  Through the 'tags'
structure, I am trying to create an api to specify the underlying data
points that make up the cache.

I disagree that it is smarter to re-generate the cache immediately on the
backend update.  Generally speaking, front end and back end code can be very
different and should be kept separate.

Also, I disagree that CMS users can tolerate a poorly responding site.
They add value to the site, and if the cache gets in their way, then they
give up on improving the quality of site content.

Cheers,

Patrick



On Fri, Jul 18, 2008 at 11:54 AM, bzcoder <bzcoder at bzcode.com> wrote:

> Patrick May wrote:
>
>> Hello,
>>
>> I'm working on a PHP cache library, and I wanted to check in and see what
>> folks thought.
>>
>> Usually, you have many different front end views that you will want to
>> cache.  These may pull from multiple datasources in odd ways.  Far away from
>> the front end, there is backend CMS, either a tool like Wordpress or Drupal,
>> or a custom tool.  Generally, I find myself managing caches by:
>>
>> 1. Putting the code that generates the cache into the front end, since it
>> is the design that dictates which pieces of information should be grouped
>> together.
>> 2. Putting a very small amount of code in the back end which causes the
>> cache to be deleted on the appropriate CRUD operations.  CMS's are
>> complicated enough as they are, and I don't want to clutter them up more
>> then necessary.
>>
>> The hard part is creating the association between the front and back end.
>>  What I want to do is to use *tags* to create this association, and to break
>> caches.
>>
>
> Part of this has to do with your system.  For example, Joomla is made up of
> Templates, Components, Modules, and Plugins all of which go into generating
> a page.
>
> A component will generate HTML content for the main section of the
> website(think displaying articles, displaying a directory, etc).
> A Module will generate a small block of HTML for specific purposes(think
> "most popular articles" list, "advertising banners", "number of users
> online")
> A template is used to put all of that together into the layout of the page.
>
> Finally, a plugin will take that page and do a bunch of regular expression
> find and replaces(so in your content, if you put {contact author} the author
> of an articles contact information is placed on the page).
>
> Therefore, Joomla has multiple levels of caching.  As I recall, you can
> have it cache the output of specific modules and you can have it cache the
> complete page output.
> Now, compare that to the Smarty template system.  In Smarty, you can cache
> the results of applying a template to generate HTML.   Smarty also has an
> invalidate function, so whenever something is changed you can run the
> invalidate function and kill the cached object.
>
>
> My feeling is it really needs to be taken to the next level.  So, when a
> cached object is generated, that object needs to record somewhere what
> underlying data points make up the cache.
> So, for example, your looking at a listing of all articles relating to PHP
> and Caching.
>
> As a first step, if an article is added, most systems just do a generic
> "invalidate all article cache files" - but a more specific function would
> say "lookup all files related to caching that where cached tagged with X and
> invalidate them".
>
> A smarter step would be to refresh the cache if possible.  So instead of
> deleting the existing cached files, generate new ones.  Considering that
> create/update operations are already expected to be slow, making them a few
> milliseconds slower is not a big deal.  Especially since the editor is a
> user you don't need to worry about getting upset at site slowness and moving
> on to a competitors site.  Wheras the reader is the person who you have to
> be quick for.
>
> However, I will say the main issue is that developers have to USE the
> cache.  It does no good to have a method of storing data in a cache unless
> the developers of the components trigger the flush/refresh mechanisms that
> are already there and most CMS systems have(similiar to the logging
> facility.  It seems every framework has one, yet how often do people
> actually add a bunch of extra code to log information except for failures).
>
>
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>



-- 
Patrick May
135 Oak Street
New York, NY 11222
+1 (347) 232-5208
patrick at hexane.org
http://www.hexane.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20080718/980a6e32/attachment.html>