> -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Rico Jansen > Verzonden: maandag 15 augustus 2005 13:35 > Aan: Discussion list for developers > Onderwerp: Re: [Developers] VOTE: new project: query cache > release framework > > > On 8/12/05, Kees Jongenburger <[EMAIL PROTECTED]> wrote: > > > > My only worry is that the administration of all this > might be more > > > > work then anticipated, both in code and execution time. > > > > > > what kind of administration do you mean? > > I think he is talking about additional cpu work that has to be > > performed in order to keep caches up 2 date and define if a > cache is > > still valid. > > Yes, additional work and information that needs to be kept to > make the strategies work. I think there will be borderline > cases or strategies in which the work will be more then the > actual query being performed. If the strategies are kept > simple and the informatie to be kept simple I think this will > be not the case. But as I have seen with some attempts to > make the multilevel cache refreshes better, the > administration took so much work as to make it useless.
I totally agree that generally simple strategies with low cost are best. But the nice thing of the proposed framework is CHOICE. If you do nothing, you have better cache management at low cost . If you want to make one small optimization based on the structure of you data, you write five lines of code and you are done. You can see the cost and benefit of it at ones. But if you want to seriously unload your database (becous for instance clustering on the application tier is cheaper) you can. This is fo corese not trivial, but it is more like a last resort optimization. Normally you won't do it, but you can. And if you do, you see what happens (or that is the idear). One issue my proposal dous not solve yet is that if you go for the last option, you would want the evaluation to happen only once, and not on all the application server nodes. But that will not be easy, if possible at all. Ernst > > -- > Rico Jansen ([EMAIL PROTECTED]) > "You call it untidy, I call it LRU ordered" -- Daniel Barlow > _______________________________________________ > Developers mailing list > [email protected] > http://lists.mmbase.org/mailman/listinfo/developers > _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
