Tommy Pham wrote:
-----Original Message-----
From: Nathan Rixham [mailto:nrixham@xxxxxxxxx]
Sent: Sunday, December 12, 2010 8:23 AM
To: Tommy Pham
Cc: 'Peter Lind'; php-general@xxxxxxxxxxxxx; 'Lester Caine'
Subject: Re: ORM doctrine
Tommy Pham wrote:
-----Original Message-----
From: Peter Lind [mailto:peter.e.lind@xxxxxxxxx]
Sent: Sunday, December 12, 2010 5:27 AM
To: Lester Caine
Cc: php-general@xxxxxxxxxxxxx
Subject: Re: ORM doctrine
<snip>
The reason for 'caching' needs to be understood before it is applied
in
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
pages.
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:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData();
output();
With auth/acl + cache:
parseRequest()
{
// parse
// add auth/acl and redirect accordingly
}
fetchData()
{
If ($useCache) getCache();
else getFromDB();
}
output();
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:
1
--------------http---------------
2 | | |
UI UI UI
3 | | |
------------------------------
4 | |
App App
5 | |
--------------
6 |
DB
You're talking about caching 5 or 6 levels down, thus already missing 4
other opportunities, which are exponentially more important.
Best,
Nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
