> -----Original Message----- > From: Peter Lind [mailto:peter.e.l...@gmail.com] > Sent: Sunday, December 12, 2010 1:44 AM > To: Tommy Pham > Cc: php-general List > Subject: Re: [PHP] ORM doctrine > > On Sunday, 12 December 2010, Tommy Pham <tommy...@gmail.com> > wrote: > >> -----Original Message----- > >> From: Peter Lind [mailto:peter.e.l...@gmail.com] > >> Sent: Sunday, December 12, 2010 1:18 AM > >> To: Tommy Pham > >> Cc: php-general List > >> Subject: Re: [PHP] ORM doctrine > >> > >> > I understand cache well, both the benefits (save DB trip) and > >> > shortfalls (outdated by DB, management, etc.). Most of the apps > >> > that I've seen so far used cache to solve a problem that shouldn't > >> > happen in the 1st place. For example, during recent my quest > >> > looking PHP MVC framework and sample apps, I saw OpenCart, an > >> > e-commerce app based > >> on > >> > custom MVC framework. Installed it for a test run. It looks good > >> > and seems to perform well with the included sample data. Then I > >> > filled up some more sample data: over 3000 categories, over 2000 > >> > manufacturers, over 300,000 products. No other changes made such > >> > specials, features, etc. Although the app supports i18n, the > >> > sample data is just one language for a decent DB size of about > >> > 100MB. The app took over 30 seconds to respond for any link. Then > >> > I disable the cache and began debugging. I made 1 minor addition > >> > to the DB and 1 minor change in the code base - parts on 1 line - I > >> > shorten the response time by about > >> > 10 seconds. What I just did proved my 2nd and 3rd point :) > >> > > >> > Regards, > >> > Tommy > >> > > >> > >> An app that takes 30 secs to respond using cache is doing it wrong. > >> You shaving 10 secs off the request without cache is fine but you > >> should have brought it much further down with a cache. Waiting 20 > >> secs for the response is still useless. > >> > >> Regards > >> Peter > >> > >> -- > >> <hype> > >> WWW: plphp.dk / plind.dk > >> LinkedIn: plind > >> BeWelcome/Couchsurfing: Fake51 > >> Twitter: kafe15 > >> </hype> > > > > My goal wasn't to optimize any app. I just want to learn 'implement > abstract MVC concept into concrete, ...' as I mentioned in Adam's thread > about choosing framework or not. If I was to optimize it, I wouldn't have > any problems lowering the response time down to under 3 seconds w/o > cache. > > > > Regards, > > Tommy > > > > Your posts seem to indicate that caches are only useful when other parts of > the app have been done wrong. My point was that this is a fairly > fundamental misunderstanding of caches - regardless of what you are or > aren't capable of optimizing. > > Regards > Peter > > -- > <hype> > WWW: plphp.dk / plind.dk > LinkedIn: plind > BeWelcome/Couchsurfing: Fake51 > Twitter: kafe15 > </hype>
I know your intention of using cache. I know it has its uses. But for most folks, they see it as one of the main parts of the solution to performance problem. I see the application design (flow, coding best practices, etc...) is the solution while cache is merely icing on the cake, as the cliché goes. I'd would optimize the app 1st before I rely on any cache. The current project I'm working on would be able to support 10-20 languages. Each language would have 500k-750k rows in some tables. This to me is a decent size DB of around a few GB. I'm expecting the performance to diminish once the row counts approaches and go beyond 1M that's because I'm not a DBA :). IMO, for the better yield in performance: time spent optimizing the app > time spent implementing cache. Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
