> -----Original Message----- > From: Tommy Pham [mailto:tommyhp2@xxxxxxxxx] > Sent: Sunday, December 12, 2010 12:53 PM > To: 'nrixham@xxxxxxxxx' > Cc: 'Peter Lind'; 'php-general@xxxxxxxxxxxxx'; 'Lester Caine' > Subject: RE: ORM doctrine > > > -----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 That's supposed to say 'cache is irrelevant'. Time for me to hit the sack.... I've been up about 23 hours w/o caffeine :D > > 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
