> 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> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
