Yes, extending the info.magnolia.module.cache.DefaultCacheKey to include the user info should do the trick. You have always user info available in MgnlContext.getUser() so it can be easily obtained.
As for the different refresh times - changing cachePolicy can do the trick. If your policy returns "store" even when cache entry exists it will be refreshed. All you need to do is to override shouldRefresh() method from the default cache policy. Cheers, Jan On Jun 16, 2010, at 11:59 AM, Andreas Antener wrote: > Hi Jan, thanks for your reply > > I never thought of the new feature to request paragraphs only. This might > help in combination with some modifications of the cache store. > We use Magnolia as the “portal” to render the pages (for instance static > articles) and include paragraphs that show different and frequently changing > content (out of Magnolia-Models or from Struts 2 applications). Those dynamic > paragraphs sometimes can take a while to prepare their content so I indeed > mask some of the slowness. Also each of them has different data update > frequencies. > The ideal solution would be to have every part of the site cached as a > fragment with different refresh times, then the request process would only > need to merge everything and send it to the browser. > > Then there is a difference between the pages served to anonymous users and > logged-in users. But I guess caching for logged-in users could be done by > extending the cache keys with some user-group related part? > > - Andy > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Jan Haderka > Sent: Mittwoch, 16. Juni 2010 08:34 > To: Magnolia User-List > Subject: Re: [magnolia-user] Performance and caching > > We try to resolve some performance issues on a pretty complex site and > caching might just be the thing: > - Is there support for fragment caching? > > It depends. Magnolia caches the requests. If you request the fragment > (paragraph) of the page (perhaps because you want to render it within some > portal or other solution of yours) then the paragraph will be cached. You > can't define arbitrary fragments and mark them for being cached and even if > there are fragments cached they will not be used internally when composing > whole page that contains such a fragment (paragraph). > > > - Has anyone experience with fragment caching and Magnolia (even if > implemented by their own)? > > not me, tho it should not be difficult to plug in into the existing cache and > store there whatever fragments you want and use a tag to mark fragment for > caching and then when rendering a tag check the cache for existence of the > fragment first. The advantage of plugging into an existing cache would be > that the fragments get flushed when new content is published to the instance. > > > - Is there a way to enable client caching for resources only? > > and by "client caching" you mean browser caching? Sure, just use custom > browserCachePolicy implementation. (patch to add voters to the > browserCachePolicy would be welcome should you choose to contribute it). > > > - Are there other "advanced-cache" strategies than the two described here > http://documentation.magnolia-cms.com/modules/advanced-cache.html? > > With 4.3.2 you can also have cache flushed only the content that belongs into > the same subtree as the published content. This was implemented to facilitate > the multi site support but can be used in general even without having > multiple sites if you are sure that changed to your content are localized to > the subtree. > > > > At the moment we use Magnolia EE 4.2. Is there maybe a new caching feature > in 4.3 that would help me to implement/configure some of the mentioned > stuff? > > There is still no pure fragment caching. The new thing in the 4.3 is that you > can render the paragraphs on their own (and have them therefore cached), but > I'm not sure that it will help to solve whatever problems you have. > Maybe if you describe what performance issues you have and what is pretty > complex site ... there might be options to actually prevent the issues from > happening. The main goal of using the cache is to lower the load on the > server during peak traffic not to mask the slowness of creation of the > content anywhere in the system. > > Jan > > > Thanks, I will appreciate any help > - Andy > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > - > Best regards, > > Jan Haderka, PhD. > Magnolia International Ltd. > > http://www.magnolia-cms.com > > You should join us at Magnolia Conference 2010: > http://www.magnolia-cms.com/conference > > http://twitter.com/magnolia_cms > http://facebook.com/Magnolia > > -------------------------------------- > > Magnolia® - Simple Open-Source Content Management > > > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- - Best regards, Jan Haderka, PhD. Magnolia International Ltd. http://www.magnolia-cms.com You should join us at Magnolia Conference 2010: http://www.magnolia-cms.com/conference http://twitter.com/magnolia_cms http://facebook.com/Magnolia -------------------------------------- Magnolia® - Simple Open-Source Content Management ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
