Tommy Pham wrote:
-----Original Message-----
From: Nathan Rixham []
Sent: Sunday, December 12, 2010 8:23 AM
To: Tommy Pham
Cc: 'Peter Lind';; 'Lester Caine'
Subject: Re: [PHP] ORM doctrine

Tommy Pham wrote:
-----Original Message-----
From: Peter Lind []
Sent: Sunday, December 12, 2010 5:27 AM
To: Lester Caine
Subject: Re: [PHP] ORM doctrine


The reason for 'caching' needs to be understood before it is applied
order to avoid the black holes that random caching is causing
nowadays already. How often do you hear "wipe the xxx browser cache"?
And I know if I am changing theme elements in bitweaver or phpgedview
then I HAVE to wipe the cache to ensure that smarty rebuilds the relevant
Which underlines my point: caching is not icing on the cake but
should be thought of sooner in the process, contrary to Tommys point.

If the app is well designed, then you still could implement it later w/o
major rewrite.

It's only well designed if caching is considered from the start - thus, as Peter
says, caching is not the icing on the cake, but should, must, be thought of in
the initial design process - if it's not, then the app isn't well designed.

I'll take a crack at it ;)

Bare minimum:
- parseRequest();
- fetchData();
- output();

With auth / acl:
  // parse
 // add auth/acl and redirect accordingly

With auth/acl + cache:
  // parse
 // add auth/acl and redirect accordingly
   If ($useCache) getCache();
  else getFromDB();

That seems to me as a minor rewrite with lots of additional modules from bare 
minimum to auth/acl+cache, as I've stated before with the points:  Understand 
the problem, understand the objective + possible growth/expansion, app design 
(framework and what not).  So whether I choose to implement cache is relevant, 
IMO, because data to me is either cache or from DB depending in specific cases 
(which is handle by the caching module).  If from cache, that's the cache 
management problem (a shortcomings).

That is only one form of relatively minor caching, and you've already missed most of the opportunities because you're already in a dynamic application / script environment there... try scoping out to the bigger picture here:

 3 UI instances with 2 different presentation tiers
 2 Application instances
 1 db instance

And here are pretty much the full entry points

  GET /something HTTP/1.1

  POST /processor HTTP/1.1

You're job is to respond to those calls as quickly as possible,

Here are six simple interface edges you can cache on:

2  |              |               |
   UI             UI              UI
3  |              |               |
4        |              |
        App            App
5        |              |
6                |

You're talking about caching 5 or 6 levels down, thus already missing 4 other opportunities, which are exponentially more important.



PHP General Mailing List (
To unsubscribe, visit:

Reply via email to