Absolutely. Right now we have a number of queries that run on each page because we have a database that stores many clients data with certain flags in the tables set for only a specific clients views. These queries will be my first focus to cache because of the fact that they run on each page load in order to verify that the data the user is viewing is theirs alone.
At the moment though this new product isn't live and is not being interacted with by customers, only by developers. Once we open the product for Beta use by clients then we can look at doing that logging which I think will help us immensely. One thing we have learnt from the old system when we made changes is that what you think customers use a lot is not necessari On Tue, Mar 10, 2009 at 11:53 AM, Fabrice B <[email protected]>wrote: > > > Naturally there is one problem with a hash; the > > possibility that two different string would create the same hash. So > create > > two hashes and concatenate them, an SHA1 hash and an MD5 hash. > > By definition a hash is supposed to statistically avoid this problem. > But well, it doesn't cost you much time to concatenate your two hashes > if you don't trust md5 enough :-) > > >As a brief example for what I mean by overriding the doSelect method for a > > model class > > Your idea is quite simple and should work but be aware that it could > also actually make the application slower ! Cache is interesting only > if you will use (statistically) the same query more than twice in the > caching interval. So you must evaluate the number of different queries > you have, and the number of times they are used in an hour. > > If you are sure you only have 100 different queries in your whole site > and your pages are hit 10.000 times per hour, then it's worth it. If > you have 10.000 different queries (because the cirteria contains a time > () variable for example) and your pages are hit 1000 times per hour, > then you are actually slowing down the whole site by caching unique > queries. > > I would recommend to do a very quick study to identifiy the cacheable > bottlenecks. Before caching your doSelect for example, simply add a > small logging feature that you enable for a day and then count how > many different queries you had and how many times each came up. Maybe > one query represents half of your db requests and you don't even need > to cache the others :-) > > Good luck ! > > Fabrice Bernhard > -- > http://www.theodo.fr > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
