> -----Original Message----- > From: Nathan Rixham [mailto:nrixham@xxxxxxxxx] > Sent: Sunday, December 12, 2010 11:41 AM > To: Tommy Pham > Cc: 'Peter Lind'; php-general@xxxxxxxxxxxxx; 'Lester Caine' > Subject: Re: ORM doctrine > > 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 Example, user never been to site before and found link on google. 1st thing that has to be done is to insure that url is valid format and not something like /goto/here/../try/to/hack/your/server or induce some other URL hacking to create a buffer overflow. Does this involve cache? Hence parseRequest(). Second, if the URL is valid, check if the user is logged in and authorized? If the user is authorized, continue processing the request and get the data. Thus: if ($useCache) getCache(); /* handles by cache module for all thatâs needed static/dynamic */ else getFromDb();. Finally, output() is responsible for transmitting the info whether it was from cache or DB. Such as if $countries represents the list of countries, then both cache & db should return the exact values (provided no change since last cache fetch). Now that the user has been to the site and clicks on a link on the page which sends request back. Again, parseRequest(); fetchData(); and the cache module within the fetchData() has to determine where to get the required data... again - cache management problem. And so on so forth... Whether is caching is done via local filesystem on the webserver or via apc or via memcached... that's all the 'cache' module problem to me. As for levels down, the fetchData() is already considered as 1st leve, IMO, one need to ensure of valid request and authorized permission before any data retrieval is done, whether from cache or DB. The internal workings between data objects and/or arrays and the output is program flow design. Now if you're to include some AJAX async calls, each call should be treated just same... valid URL? Authorized user? Then finally fetchData(); As for whether something that's common to all or not such as list countries, and if it's to get from cache, then that's the cache management problem (as I've said, shortcoming). If it's from DB, DB is already cached. Case in point, I run a 2 table join query for 3k+ categories on MySQL workbench. 1st time execution: duration .125 sec/ fetch .032 sec. 2nd time execution after a query of manufacturers: duration 0/ fetch 0. 3rd time execution on a separate instance of workbench: duration 0 / fetch 0. Regards, Tommy Disclaimer: data in this context is considered as anything that's not 100% static images, css, js, etc... files. Whether it's PHP generating 100% of the form input, generated PDF doc, fetching a list rows from a particular table in the DB, etc., what's get cached or not depends all on the cache module and its cache management inside the fetchData(). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
