Re: AW: @Cached and caching in general
I mean exactly that, I'm comfortable with my html code, css and js I can inline what I need, I'm not proposing this as a general approach, but I like doing just that: take part of rendered content and do something with it. if something is a compoenent framework, a component should be independant, even after the html code is rendered. Davor Hrg On Wed, Mar 19, 2008 at 10:45 AM, Martin Kersten <[EMAIL PROTECTED]> wrote: > > ...this king of component is useful for capturing output so it can be sent > > via email for example. > > This does not sound like a good idea. Do you mean requesting a page and cut > it out or grabbing part of the DOM during same request. Just wondering... . > > -Ursprüngliche Nachricht- > Von: Davor Hrg [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 19. März 2008 10:42 > An: Tapestry users > Betreff: Re: AW: @Cached and caching in general > > > > I agree that this is not something to take on lightly, and data should be > cached, and rendering left as is. > but besides caching this king of component is useful for capturing output so > it can be sent via email for example. > > I like to keep most things stateless (only dependant on parameters), so from > time to time I can use some of these nasty tricks. > > Davor Hrg > > On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > :) > > > > True. I definitely won't say that this will solve all cases 100%. > > But for basic rendering.. this allows you to essentially set > > "expires" for fragments of the page. And yes it caches all > > operations that go through PageRenderSupport. And if I could take > > over the markupWriter properly, I would have cached and replayed > > those already.. but i couldn't easily do that.. But on second > > thought, you're right, maybe I should have cached a DOM tree.. since > > it would have a much better guarantees for replaying. > > > > But on most cases, this component works pretty darn good, and we love it. > > > > Of course trying to do evict cache on particular events is hard.. but > > if you are alright with "updates within 30hr" sort of cases. this is > > a good start. > > > > > > > > > > > > Howard Lewis Ship wrote: > > > I'm generally against these approached. > > > > > > Cache the data, make it fast to access. > > > > > > Let Tapestry do a full render every time. > > > > > > You'll end up with confusing, unforseen consequences. > > > > > > Rendering is increasingly a complex dance between components. > > That's > the power and the penalty of Tapestry. Components inside > > that cached > zone are not just rendering a character stream, they > > are generating > JavaScript, assigning unique ids (via > > PageRenderSupport) interacting > with an enclosing Form components, > > and doing other user-specific > things. > > > > > > I would always look elsewhere first for places that need > > optimization, > and I'd start with database access and queries. > > > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > > >> We have a component that we call "Buffer" :) it takes a timeout, > > >> optional cachekey, and optional lastmodified (to tell you) >> >> > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > > >> liberate it.. you would just have to change the cache hooks to use > > >> whatever cache you want to use... > > >> > > >> The easiest way to add caching to the app. :) >> >> >> >> > > Martin Kersten wrote: > > >> > @Chached is only used during a single page rendering cycle. It > > would not >> > apply to your situation. (as far as I know) >> > > > >> > Source: > > >> > > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > >> > > > >> > Your scenario would be implementable using your own component. > > >> > The component would represent a fragment and read the file > > (even >> > use a inmemory cache strategy (soft/weakreferences)) and > > write >> > the ouput directly to stream (or actually the dom tree of > > your >> > document being returned). > > >> > > > >>
Re: AW: @Cached and caching in general
Well, i believe if someone is aware of these issues, there's nothing wrong with using this solution - I've had some cases where data access is fast but data processing (in order to present) was quite complex, so this really helped. For reference, another not-yet-mentioned problem of this kind of cache is the jsessionid parameter that may be cached in url (though we / many people completely remove them nowadays) On Wed, Mar 19, 2008 at 1:55 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I'm generally against these approached. > > Cache the data, make it fast to access. > > Let Tapestry do a full render every time. > > You'll end up with confusing, unforseen consequences. > > Rendering is increasingly a complex dance between components. That's > the power and the penalty of Tapestry. Components inside that cached > zone are not just rendering a character stream, they are generating > JavaScript, assigning unique ids (via PageRenderSupport) interacting > with an enclosing Form components, and doing other user-specific > things. > > I would always look elsewhere first for places that need optimization, > and I'd start with database access and queries. > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > We have a component that we call "Buffer" :) it takes a timeout, > > optional cachekey, and optional lastmodified (to tell you) > > > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > > liberate it.. you would just have to change the cache hooks to use > > whatever cache you want to use... > > > > The easiest way to add caching to the app. :) > > > > > > > > Martin Kersten wrote: > > > @Chached is only used during a single page rendering cycle. It would not > > > apply to your situation. (as far as I know) > > > > > > Source: > > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > > > > > Your scenario would be implementable using your own component. > > > The component would represent a fragment and read the file (even > > > use a inmemory cache strategy (soft/weakreferences)) and write > > > the ouput directly to stream (or actually the dom tree of your > > > document being returned). > > > > > > Using your own solution enables you to mimic the behavior you talk > about. > > > Another idea would to write / cache only datas needed to render the > tables > > > (e.g. cache only content not markup). Never the less I am in doupt, > > > if such a solution is necessary (dynamically cache results of > > > database queries in memory or on disk). > > > > > > So after all you might want to port your application. As always use > > > the simpliest solution first. So database queries without any caches. > > > Once you see any problems (performance is below required) just go for > > > optimization. Since you have a fallback solution at hand (cron-jobs + > > > disk fragments) you are at the safe side. But I am in doupt if you > > > really need the markup being cached. Caching the database results > > > and recreate markup sounds more reasonable. You might save you lots > > > of seeking time. > > > > > > But you always know: Only the code / application will tell you! > > > > > > > > > Cheers, > > > > > > Martin (Kersten) > > > > > > -Ursprüngliche Nachricht- > > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 18. März 2008 17:45 > > > An: Tapestry users > > > Betreff: @Cached and caching in general > > > > > > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > > > > > > Or is this a pure memory-based cache? > > > > > > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > > > > > > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > > > > > Somehow I don't trust Hibernate for high-performance database queries > on huge tables as I think if tables are huge and many people access it, > it will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > > > > > > So I think the best solution is always to generate HTML fragments in > the background that take a long time and simple "include" themthis is > even quicker then parsing templates when the data is cached. So you save the > time necessary for querying the database plus the time necessary for > processing the templates that are involved. > > > > > > Currently the setup on this application uses one-way database > replication and the cron jobs access the the
AW: AW: @Cached and caching in general
> ...this king of component is useful for capturing output so it can be sent > via email for example. This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... . -Ursprüngliche Nachricht- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 19. März 2008 10:42 An: Tapestry users Betreff: Re: AW: @Cached and caching in general I agree that this is not something to take on lightly, and data should be cached, and rendering left as is. but besides caching this king of component is useful for capturing output so it can be sent via email for example. I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks. Davor Hrg On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > :) > > True. I definitely won't say that this will solve all cases 100%. > But for basic rendering.. this allows you to essentially set > "expires" for fragments of the page. And yes it caches all > operations that go through PageRenderSupport. And if I could take > over the markupWriter properly, I would have cached and replayed > those already.. but i couldn't easily do that.. But on second > thought, you're right, maybe I should have cached a DOM tree.. since > it would have a much better guarantees for replaying. > > But on most cases, this component works pretty darn good, and we love it. > > Of course trying to do evict cache on particular events is hard.. but > if you are alright with "updates within 30hr" sort of cases. this is > a good start. > > > > > > Howard Lewis Ship wrote: > > I'm generally against these approached. > > > > Cache the data, make it fast to access. > > > > Let Tapestry do a full render every time. > > > > You'll end up with confusing, unforseen consequences. > > > > Rendering is increasingly a complex dance between components. > That's > the power and the penalty of Tapestry. Components inside > that cached > zone are not just rendering a character stream, they > are generating > JavaScript, assigning unique ids (via > PageRenderSupport) interacting > with an enclosing Form components, > and doing other user-specific > things. > > > > I would always look elsewhere first for places that need > optimization, > and I'd start with database access and queries. > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > >> We have a component that we call "Buffer" :) it takes a timeout, > >> optional cachekey, and optional lastmodified (to tell you) >> >> > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > >> liberate it.. you would just have to change the cache hooks to use > >> whatever cache you want to use... > >> > >> The easiest way to add caching to the app. :) >> >> >> >> > Martin Kersten wrote: > >> > @Chached is only used during a single page rendering cycle. It > would not >> > apply to your situation. (as far as I know) >> > > >> > Source: > >> > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > > >> > Your scenario would be implementable using your own component. > >> > The component would represent a fragment and read the file > (even >> > use a inmemory cache strategy (soft/weakreferences)) and > write >> > the ouput directly to stream (or actually the dom tree of > your >> > document being returned). > >> > > >> > Using your own solution enables you to mimic the behavior you talk > about. > >> > Another idea would to write / cache only datas needed to render > the tables >> > (e.g. cache only content not markup). Never the less > I am in doupt, >> > if such a solution is necessary (dynamically > cache results of >> > database queries in memory or on disk). > >> > > >> > So after all you might want to port your application. As always > use >> > the simpliest solution first. So database queries without any > caches. > >> > Once you see any problems (performance is below required) just > go for >> > optimization. Since you have a fallback solution at hand > (cron-jobs + >> > disk fragments) you are at the safe side. But I am > in doupt if you >
Re: AW: @Cached and caching in general
I agree that this is not something to take on lightly, and data should be cached, and rendering left as is. but besides caching this king of component is useful for capturing output so it can be sent via email for example. I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks. Davor Hrg On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > :) > > True. I definitely won't say that this will solve all cases 100%. But > for basic rendering.. this allows you to essentially set "expires" for > fragments of the page. And yes it caches all operations that go through > PageRenderSupport. And if I could take over the markupWriter properly, > I would have cached and replayed those already.. but i couldn't easily > do that.. But on second thought, you're right, maybe I should have > cached a DOM tree.. since it would have a much better guarantees for > replaying. > > But on most cases, this component works pretty darn good, and we love it. > > Of course trying to do evict cache on particular events is hard.. but if > you are alright with "updates within 30hr" sort of cases. this is a good > start. > > > > > > Howard Lewis Ship wrote: > > I'm generally against these approached. > > > > Cache the data, make it fast to access. > > > > Let Tapestry do a full render every time. > > > > You'll end up with confusing, unforseen consequences. > > > > Rendering is increasingly a complex dance between components. That's > > the power and the penalty of Tapestry. Components inside that cached > > zone are not just rendering a character stream, they are generating > > JavaScript, assigning unique ids (via PageRenderSupport) interacting > > with an enclosing Form components, and doing other user-specific > > things. > > > > I would always look elsewhere first for places that need optimization, > > and I'd start with database access and queries. > > > > On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > >> We have a component that we call "Buffer" :) it takes a timeout, > >> optional cachekey, and optional lastmodified (to tell you) > >> > >> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > >> liberate it.. you would just have to change the cache hooks to use > >> whatever cache you want to use... > >> > >> The easiest way to add caching to the app. :) > >> > >> > >> > >> Martin Kersten wrote: > >> > @Chached is only used during a single page rendering cycle. It would > not > >> > apply to your situation. (as far as I know) > >> > > >> > Source: > >> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > > >> > Your scenario would be implementable using your own component. > >> > The component would represent a fragment and read the file (even > >> > use a inmemory cache strategy (soft/weakreferences)) and write > >> > the ouput directly to stream (or actually the dom tree of your > >> > document being returned). > >> > > >> > Using your own solution enables you to mimic the behavior you talk > about. > >> > Another idea would to write / cache only datas needed to render the > tables > >> > (e.g. cache only content not markup). Never the less I am in doupt, > >> > if such a solution is necessary (dynamically cache results of > >> > database queries in memory or on disk). > >> > > >> > So after all you might want to port your application. As always use > >> > the simpliest solution first. So database queries without any caches. > >> > Once you see any problems (performance is below required) just go for > >> > optimization. Since you have a fallback solution at hand (cron-jobs + > >> > disk fragments) you are at the safe side. But I am in doupt if you > >> > really need the markup being cached. Caching the database results > >> > and recreate markup sounds more reasonable. You might save you lots > >> > of seeking time. > >> > > >> > But you always know: Only the code / application will tell you! > >> > > >> > > >> > Cheers, > >> > > >> > Martin (Kersten) > >> > > >> > -Ursprüngliche Nachricht- > >> > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >> > Gesendet: Dienstag, 18. März 2008 17:45 > >> > An: Tapestry users > >> > Betreff: @Cached and caching in general > >> > > >> > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > >> > > >> > Or is this a pure memory-based cache? > >> > > >> > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > >> > > >> > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are included to > reduce the da
Re: AW: @Cached and caching in general
:) True. I definitely won't say that this will solve all cases 100%. But for basic rendering.. this allows you to essentially set "expires" for fragments of the page. And yes it caches all operations that go through PageRenderSupport. And if I could take over the markupWriter properly, I would have cached and replayed those already.. but i couldn't easily do that.. But on second thought, you're right, maybe I should have cached a DOM tree.. since it would have a much better guarantees for replaying. But on most cases, this component works pretty darn good, and we love it. Of course trying to do evict cache on particular events is hard.. but if you are alright with "updates within 30hr" sort of cases. this is a good start. Howard Lewis Ship wrote: I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: We have a component that we call "Buffer" :) it takes a timeout, optional cachekey, and optional lastmodified (to tell you) We have it for Tap4 and Tap5, if anyone really wants it, I bet I can liberate it.. you would just have to change the cache hooks to use whatever cache you want to use... The easiest way to add caching to the app. :) Martin Kersten wrote: > @Chached is only used during a single page rendering cycle. It would not > apply to your situation. (as far as I know) > > Source: > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > Your scenario would be implementable using your own component. > The component would represent a fragment and read the file (even > use a inmemory cache strategy (soft/weakreferences)) and write > the ouput directly to stream (or actually the dom tree of your > document being returned). > > Using your own solution enables you to mimic the behavior you talk about. > Another idea would to write / cache only datas needed to render the tables > (e.g. cache only content not markup). Never the less I am in doupt, > if such a solution is necessary (dynamically cache results of > database queries in memory or on disk). > > So after all you might want to port your application. As always use > the simpliest solution first. So database queries without any caches. > Once you see any problems (performance is below required) just go for > optimization. Since you have a fallback solution at hand (cron-jobs + > disk fragments) you are at the safe side. But I am in doupt if you > really need the markup being cached. Caching the database results > and recreate markup sounds more reasonable. You might save you lots > of seeking time. > > But you always know: Only the code / application will tell you! > > > Cheers, > > Martin (Kersten) > > -Ursprüngliche Nachricht- > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 18. März 2008 17:45 > An: Tapestry users > Betreff: @Cached and caching in general > > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? > > Or is this a pure memory-based cache? > > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. > > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). > > Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. > > So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" themthis is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved. > > Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applicatio
Re: AW: @Cached and caching in general
I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > We have a component that we call "Buffer" :) it takes a timeout, > optional cachekey, and optional lastmodified (to tell you) > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > liberate it.. you would just have to change the cache hooks to use > whatever cache you want to use... > > The easiest way to add caching to the app. :) > > > > Martin Kersten wrote: > > @Chached is only used during a single page rendering cycle. It would not > > apply to your situation. (as far as I know) > > > > Source: > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > > > Your scenario would be implementable using your own component. > > The component would represent a fragment and read the file (even > > use a inmemory cache strategy (soft/weakreferences)) and write > > the ouput directly to stream (or actually the dom tree of your > > document being returned). > > > > Using your own solution enables you to mimic the behavior you talk about. > > Another idea would to write / cache only datas needed to render the tables > > (e.g. cache only content not markup). Never the less I am in doupt, > > if such a solution is necessary (dynamically cache results of > > database queries in memory or on disk). > > > > So after all you might want to port your application. As always use > > the simpliest solution first. So database queries without any caches. > > Once you see any problems (performance is below required) just go for > > optimization. Since you have a fallback solution at hand (cron-jobs + > > disk fragments) you are at the safe side. But I am in doupt if you > > really need the markup being cached. Caching the database results > > and recreate markup sounds more reasonable. You might save you lots > > of seeking time. > > > > But you always know: Only the code / application will tell you! > > > > > > Cheers, > > > > Martin (Kersten) > > > > -Ursprüngliche Nachricht- > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 18. März 2008 17:45 > > An: Tapestry users > > Betreff: @Cached and caching in general > > > > I have not used T5 yet, but would @Cached use the file system for caching > HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has really > a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to cron > jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > > > Somehow I don't trust Hibernate for high-performance database queries on > huge tables as I think if tables are huge and many people access it, it > will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments in the > background that take a long time and simple "include" themthis is even > quicker then parsing templates when the data is cached. So you save the time > necessary for querying the database plus the time necessary for processing > the templates that are involved. > > > > Currently the setup on this application uses one-way database replication > and the cron jobs access the the huge data table on the replicated database > and generate those HTML fragments without disturbing the web-applications > performance. So the main application simply includes those HTML fragments > within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --
Re: AW: @Cached and caching in general
thanks :) It's 00:46 here, I'll try it out in the morning, If I make it work I'll create a wiki page for it... Davor Hrg On Wed, Mar 19, 2008 at 12:38 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > here you go :) > > Should be able to drop these into your project. > > The Buffer.java is the component ( so somewhere under components package > ), and the BufferServices needs to go somewhere where Tapestry will not > enhance it, so I put it under the services package. ). :) Sorry, but > the "cacheKey/Extra" stuff is a little confusing, but maybe we can start > a different thread/docs for that, or simplify to make it easier for > generalization.. > > The Parameters are: > > 1) timeout: String >a duration in which a cache value will be valid; format: "hh:mm:ss" >if you want a one hour timeout: "01:00:00". >if you want a 30 min timeout: "00:30:00" > > 2) lastUpdated: Date >it output this parameter (if bound), to let you know when the contents >of the Buffer were last updated. So you can print out a small message >"Last Updated ##" > > > 3) cacheKey: String > 4) cacehKeyExtra: String > > here is where it might get a little confusing.. it generates a key > into the cache using the request server/port/context/path and cacheKey > and cacheKeyExtra. So it focuses the cache onto the current server > and webapp ( since we used a shared memcache this avoids developers > and production webapps stepping on each others toes ). It then > adds cacheKey (which defaults to the component's extendedId), and > cacheKeyExtra (which defaults to empty). > > So by default just wrapping your stuff with will just > work since the key will be something like > "server:port/context_PageName:buffer_#". > > You would set cacheKey if you wanted to generalize the contents of the > buffer ( have the same Buffer component shared across pages ). > > You would set cacheKeyExtra if you wanted to specialize the contents of > the buffer ( have the same Buffer component apply to subsets of > request.. like if it's user specific ). > > > > > > > > > > > Davor Hrg wrote: > > I'm interested in the one for T5 :) > > > > if you are not allowed to share source, > > maybe few hints how to make it > > > > Davor Hrg > > > > On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > >> We have a component that we call "Buffer" :) it takes a timeout, > >> optional cachekey, and optional lastmodified (to tell you) > >> > >> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > >> liberate it.. you would just have to change the cache hooks to use > >> whatever cache you want to use... > >> > >> The easiest way to add caching to the app. :) > >> > >> > >> > >> Martin Kersten wrote: > >> > @Chached is only used during a single page rendering cycle. It would > not > >> > apply to your situation. (as far as I know) > >> > > >> > Source: > >> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > > >> > Your scenario would be implementable using your own component. > >> > The component would represent a fragment and read the file (even > >> > use a inmemory cache strategy (soft/weakreferences)) and write > >> > the ouput directly to stream (or actually the dom tree of your > >> > document being returned). > >> > > >> > Using your own solution enables you to mimic the behavior you talk > about. > >> > Another idea would to write / cache only datas needed to render the > tables > >> > (e.g. cache only content not markup). Never the less I am in doupt, > >> > if such a solution is necessary (dynamically cache results of > >> > database queries in memory or on disk). > >> > > >> > So after all you might want to port your application. As always use > >> > the simpliest solution first. So database queries without any caches. > >> > Once you see any problems (performance is below required) just go for > >> > optimization. Since you have a fallback solution at hand (cron-jobs + > >> > disk fragments) you are at the safe side. But I am in doupt if you > >> > really need the markup being cached. Caching the database results > >> > and recreate markup sounds more reasonable. You might save you lots > >> > of seeking time. > >> > > >> > But you always know: Only the code / application will tell you! > >> > > >> > > >> > Cheers, > >> > > >> > Martin (Kersten) > >> > > >> > -Ursprüngliche Nachricht- > >> > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >> > Gesendet: Dienstag, 18. März 2008 17:45 > >> > An: Tapestry users > >> > Betreff: @Cached and caching in general > >> > > >> > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > >> > > >> > Or is this a pure memory-based cache? > >> > > >> > I am thinking about migrating an old PHP
Re: AW: @Cached and caching in general
here you go :) Should be able to drop these into your project. The Buffer.java is the component ( so somewhere under components package ), and the BufferServices needs to go somewhere where Tapestry will not enhance it, so I put it under the services package. ). :) Sorry, but the "cacheKey/Extra" stuff is a little confusing, but maybe we can start a different thread/docs for that, or simplify to make it easier for generalization.. The Parameters are: 1) timeout: String a duration in which a cache value will be valid; format: "hh:mm:ss" if you want a one hour timeout: "01:00:00". if you want a 30 min timeout: "00:30:00" 2) lastUpdated: Date it output this parameter (if bound), to let you know when the contents of the Buffer were last updated. So you can print out a small message "Last Updated ##" 3) cacheKey: String 4) cacehKeyExtra: String here is where it might get a little confusing.. it generates a key into the cache using the request server/port/context/path and cacheKey and cacheKeyExtra. So it focuses the cache onto the current server and webapp ( since we used a shared memcache this avoids developers and production webapps stepping on each others toes ). It then adds cacheKey (which defaults to the component's extendedId), and cacheKeyExtra (which defaults to empty). So by default just wrapping your stuff with will just work since the key will be something like "server:port/context_PageName:buffer_#". You would set cacheKey if you wanted to generalize the contents of the buffer ( have the same Buffer component shared across pages ). You would set cacheKeyExtra if you wanted to specialize the contents of the buffer ( have the same Buffer component apply to subsets of request.. like if it's user specific ). Davor Hrg wrote: I'm interested in the one for T5 :) if you are not allowed to share source, maybe few hints how to make it Davor Hrg On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: We have a component that we call "Buffer" :) it takes a timeout, optional cachekey, and optional lastmodified (to tell you) We have it for Tap4 and Tap5, if anyone really wants it, I bet I can liberate it.. you would just have to change the cache hooks to use whatever cache you want to use... The easiest way to add caching to the app. :) Martin Kersten wrote: > @Chached is only used during a single page rendering cycle. It would not > apply to your situation. (as far as I know) > > Source: > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > Your scenario would be implementable using your own component. > The component would represent a fragment and read the file (even > use a inmemory cache strategy (soft/weakreferences)) and write > the ouput directly to stream (or actually the dom tree of your > document being returned). > > Using your own solution enables you to mimic the behavior you talk about. > Another idea would to write / cache only datas needed to render the tables > (e.g. cache only content not markup). Never the less I am in doupt, > if such a solution is necessary (dynamically cache results of > database queries in memory or on disk). > > So after all you might want to port your application. As always use > the simpliest solution first. So database queries without any caches. > Once you see any problems (performance is below required) just go for > optimization. Since you have a fallback solution at hand (cron-jobs + > disk fragments) you are at the safe side. But I am in doupt if you > really need the markup being cached. Caching the database results > and recreate markup sounds more reasonable. You might save you lots > of seeking time. > > But you always know: Only the code / application will tell you! > > > Cheers, > > Martin (Kersten) > > -Ursprüngliche Nachricht- > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 18. März 2008 17:45 > An: Tapestry users > Betreff: @Cached and caching in general > > I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? > > Or is this a pure memory-based cache? > > I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. > > It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). > > Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. > > So I think the best solution is always to generate HTML fragme
Re: AW: @Cached and caching in general
I'm interested in the one for T5 :) if you are not allowed to share source, maybe few hints how to make it Davor Hrg On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > We have a component that we call "Buffer" :) it takes a timeout, > optional cachekey, and optional lastmodified (to tell you) > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > liberate it.. you would just have to change the cache hooks to use > whatever cache you want to use... > > The easiest way to add caching to the app. :) > > > > Martin Kersten wrote: > > @Chached is only used during a single page rendering cycle. It would not > > apply to your situation. (as far as I know) > > > > Source: > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > > > Your scenario would be implementable using your own component. > > The component would represent a fragment and read the file (even > > use a inmemory cache strategy (soft/weakreferences)) and write > > the ouput directly to stream (or actually the dom tree of your > > document being returned). > > > > Using your own solution enables you to mimic the behavior you talk about. > > Another idea would to write / cache only datas needed to render the tables > > (e.g. cache only content not markup). Never the less I am in doupt, > > if such a solution is necessary (dynamically cache results of > > database queries in memory or on disk). > > > > So after all you might want to port your application. As always use > > the simpliest solution first. So database queries without any caches. > > Once you see any problems (performance is below required) just go for > > optimization. Since you have a fallback solution at hand (cron-jobs + > > disk fragments) you are at the safe side. But I am in doupt if you > > really need the markup being cached. Caching the database results > > and recreate markup sounds more reasonable. You might save you lots > > of seeking time. > > > > But you always know: Only the code / application will tell you! > > > > > > Cheers, > > > > Martin (Kersten) > > > > -Ursprüngliche Nachricht- > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 18. März 2008 17:45 > > An: Tapestry users > > Betreff: @Cached and caching in general > > > > I have not used T5 yet, but would @Cached use the file system for caching > HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has really > a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to cron > jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > > > Somehow I don't trust Hibernate for high-performance database queries on > huge tables as I think if tables are huge and many people access it, it > will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments in the > background that take a long time and simple "include" themthis is even > quicker then parsing templates when the data is cached. So you save the time > necessary for querying the database plus the time necessary for processing > the templates that are involved. > > > > Currently the setup on this application uses one-way database replication > and the cron jobs access the the huge data table on the replicated database > and generate those HTML fragments without disturbing the web-applications > performance. So the main application simply includes those HTML fragments > within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
I had done http://andyhot.di.uoa.gr/tapfx/app?service=page/Cache for T3 and T4 @ http://tapfx.sourceforge.net/ but it needed ehcache Perhaps combine the two (esp. since there's no T5 version) and move to tacos? On Tue, Mar 18, 2008 at 8:22 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > We have a component that we call "Buffer" :) it takes a timeout, > optional cachekey, and optional lastmodified (to tell you) > > We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > liberate it.. you would just have to change the cache hooks to use > whatever cache you want to use... > > The easiest way to add caching to the app. :) > > > > Martin Kersten wrote: > > @Chached is only used during a single page rendering cycle. It would not > > apply to your situation. (as far as I know) > > > > Source: > > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > > > Your scenario would be implementable using your own component. > > The component would represent a fragment and read the file (even > > use a inmemory cache strategy (soft/weakreferences)) and write > > the ouput directly to stream (or actually the dom tree of your > > document being returned). > > > > Using your own solution enables you to mimic the behavior you talk about. > > Another idea would to write / cache only datas needed to render the tables > > (e.g. cache only content not markup). Never the less I am in doupt, > > if such a solution is necessary (dynamically cache results of > > database queries in memory or on disk). > > > > So after all you might want to port your application. As always use > > the simpliest solution first. So database queries without any caches. > > Once you see any problems (performance is below required) just go for > > optimization. Since you have a fallback solution at hand (cron-jobs + > > disk fragments) you are at the safe side. But I am in doupt if you > > really need the markup being cached. Caching the database results > > and recreate markup sounds more reasonable. You might save you lots > > of seeking time. > > > > But you always know: Only the code / application will tell you! > > > > > > Cheers, > > > > Martin (Kersten) > > > > -Ursprüngliche Nachricht- > > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 18. März 2008 17:45 > > An: Tapestry users > > Betreff: @Cached and caching in general > > > > I have not used T5 yet, but would @Cached use the file system for caching > HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has really > a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to cron > jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > > > Somehow I don't trust Hibernate for high-performance database queries on > huge tables as I think if tables are huge and many people access it, it > will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments in the > background that take a long time and simple "include" themthis is even > quicker then parsing templates when the data is cached. So you save the time > necessary for querying the database plus the time necessary for processing > the templates that are involved. > > > > Currently the setup on this application uses one-way database replication > and the cron jobs access the the huge data table on the replicated database > and generate those HTML fragments without disturbing the web-applications > performance. So the main application simply includes those HTML fragments > within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
We have a component that we call "Buffer" :) it takes a timeout, optional cachekey, and optional lastmodified (to tell you) We have it for Tap4 and Tap5, if anyone really wants it, I bet I can liberate it.. you would just have to change the cache hooks to use whatever cache you want to use... The easiest way to add caching to the app. :) Martin Kersten wrote: @Chached is only used during a single page rendering cycle. It would not apply to your situation. (as far as I know) Source: http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ Your scenario would be implementable using your own component. The component would represent a fragment and read the file (even use a inmemory cache strategy (soft/weakreferences)) and write the ouput directly to stream (or actually the dom tree of your document being returned). Using your own solution enables you to mimic the behavior you talk about. Another idea would to write / cache only datas needed to render the tables (e.g. cache only content not markup). Never the less I am in doupt, if such a solution is necessary (dynamically cache results of database queries in memory or on disk). So after all you might want to port your application. As always use the simpliest solution first. So database queries without any caches. Once you see any problems (performance is below required) just go for optimization. Since you have a fallback solution at hand (cron-jobs + disk fragments) you are at the safe side. But I am in doupt if you really need the markup being cached. Caching the database results and recreate markup sounds more reasonable. You might save you lots of seeking time. But you always know: Only the code / application will tell you! Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:45 An: Tapestry users Betreff: @Cached and caching in general I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? Or is this a pure memory-based cache? I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" themthis is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved. Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds. But maybe the T5 caching mechanism would make all of those low-level tricks redundant? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
Tobias is right to ask about his, I'm usin php for a long time now and output_buffer functions "ob_*" are great for simplifying complex pages, adding caching without interferring with internal code people have asked about getting html output of page and etc. if framework would allow access to markup on afterRenderTemplate and if markup could be forced to serialize all HTML of the current element it would allow creating a simple component that can wrap a part of (processor heavy) code and catch the rendered markup. Then it would allow it self to be rendered normaly only in some intervals and produce cached raw output otherwise. this would be very similar to output_buffer tricks in php. Davor Hrg On Tue, Mar 18, 2008 at 6:25 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > That's a special case, really. Do what you want. > > -Filip > > > > On 2008-03-18 18:20, Tobias Marx wrote: > > Ok...let's say factor 10 (unless you have many loops inside of loops > inside of loops that use queries on large tables). > > > > Original-Nachricht > >> Datum: Tue, 18 Mar 2008 18:14:28 +0100 > >> Von: "Filip S. Adamsen" <[EMAIL PROTECTED]> > >> An: Tapestry users > >> Betreff: Re: AW: @Cached and caching in general > > > >> A factor 100?? C'mon. If, and I stress IF, your application would > >> benefit that much from this, fine. But Tapestry 5 applications in > >> general would - I guarantee you - not see such an improvement. > >> > >> -Filip > >> > >> On 2008-03-18 18:07, Tobias Marx wrote: > >>> My theory is that such a disk-caching behaviour could speed up Tapestry > >> applications by factor 100although Tapestry 5 is quite fast. > >>> The template parsing is still quite slow because it uses Velocity and > >> everything that avoids template parsing would increase the speed a lot. > >>> > >>> Original-Nachricht > >>>> Datum: Tue, 18 Mar 2008 18:01:40 +0100 > >>>> Von: "Martin Kersten" <[EMAIL PROTECTED]> > >>>> An: "Tapestry users" > >>>> Betreff: AW: @Cached and caching in general > >>>> @Chached is only used during a single page rendering cycle. It would > >> not > >>>> apply to your situation. (as far as I know) > >>>> > >>>> Source: > >>>> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >>>> > >>>> Your scenario would be implementable using your own component. > >>>> The component would represent a fragment and read the file (even > >>>> use a inmemory cache strategy (soft/weakreferences)) and write > >>>> the ouput directly to stream (or actually the dom tree of your > >>>> document being returned). > >>>> > >>>> Using your own solution enables you to mimic the behavior you talk > >> about. > >>>> Another idea would to write / cache only datas needed to render the > >> tables > >>>> (e.g. cache only content not markup). Never the less I am in doupt, > >>>> if such a solution is necessary (dynamically cache results of > >>>> database queries in memory or on disk). > >>>> > >>>> So after all you might want to port your application. As always use > >>>> the simpliest solution first. So database queries without any caches. > >>>> Once you see any problems (performance is below required) just go for > >>>> optimization. Since you have a fallback solution at hand (cron-jobs + > >>>> disk fragments) you are at the safe side. But I am in doupt if you > >>>> really need the markup being cached. Caching the database results > >>>> and recreate markup sounds more reasonable. You might save you lots > >>>> of seeking time. > >>>> > >>>> But you always know: Only the code / application will tell you! > >>>> > >>>> > >>>> Cheers, > >>>> > >>>> Martin (Kersten) > >>>> > >>>> -Ursprüngliche Nachricht- > >>>> Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >>>> Gesendet: Dienstag, 18. März 2008 17:45 > >>>> An: Tapestry users > >>>> Betreff: @Cached and caching in general > >>>> > >>>> I have not used
AW: @Cached and caching in general
I had the idea while looking at this benchmark here: http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/throughput.gif I am currently trying out Resin as it allows to use PHP and Servlets at the same time - so you can mix old PHP code with Tapestry on a single webserver and replace parts of the web application with PHP or Tapestry depending on whats faster in a certain situation. A typical example I have problems with in Tapestry/Hibernate is the following: - a table that displays an object - buttons or additional components on the table cells that depend on other objects In this case you have several database queriesone for the outer loop and one for the inner loops. In theory you could define a virtual new object in Hibernate that does some joins or unions that will result in just one query in the outer loop...and then it works quite fast. I like Hibernate as long as you can use your objects directly...but using Hibernate for joins and unions is not much fun So such a table would benefit a lot if is was cached...even if the individual queries would be cached you still had to do all the loops and parsing of the templates. Original-Nachricht > Datum: Tue, 18 Mar 2008 18:22:01 +0100 > Von: "Martin Kersten" <[EMAIL PROTECTED]> > An: "Tapestry users" > Betreff: AW: @Cached and caching in general > You might want to know what tapestry does with your templates. > Tapestry reads your template and parses it - only once it changes! > So generating two pages (even with different content) just results > in using a parsed, preprocessed in memory representation of your > template. So tapestry strictly avoids disk-access and parsing > in production (when processing all templates on startup is > enabled). > > So there is no need for the older cache it hack. As I mentioned > it is easy to play with your own cache implementation. But be > carefull about the components you place inside your cache. You > know context and event handling. But for displaying 'cached' content > it might be an option. > > If you go ahead and try it you may post your benchmarks. I don't > know who has stretched it before but I guess caching is always a > hot topic so if you can provide new insides your are welcome. > > > Cheers, > > Martin (Kersten) > > > > -Ursprüngliche Nachricht- > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 18. März 2008 18:15 > An: Tapestry users > Betreff: AW: @Cached and caching in general > > > The problem is context I guess. Usally your component depends on lots > > of stuff. Parameters, URL, Services, Page-state, component state, > > HTTP-Parameters and so on. > > Yes...but it must be possible somehow as some PHP template engines also do > it. Isn't there already some mechanism in the internals of Tapestry that > keeps track of that even now? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
That's a special case, really. Do what you want. -Filip On 2008-03-18 18:20, Tobias Marx wrote: Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables). Original-Nachricht Datum: Tue, 18 Mar 2008 18:14:28 +0100 Von: "Filip S. Adamsen" <[EMAIL PROTECTED]> An: Tapestry users Betreff: Re: AW: @Cached and caching in general A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: "Martin Kersten" <[EMAIL PROTECTED]> An: "Tapestry users" Betreff: AW: @Cached and caching in general @Chached is only used during a single page rendering cycle. It would not apply to your situation. (as far as I know) Source: http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ Your scenario would be implementable using your own component. The component would represent a fragment and read the file (even use a inmemory cache strategy (soft/weakreferences)) and write the ouput directly to stream (or actually the dom tree of your document being returned). Using your own solution enables you to mimic the behavior you talk about. Another idea would to write / cache only datas needed to render the tables (e.g. cache only content not markup). Never the less I am in doupt, if such a solution is necessary (dynamically cache results of database queries in memory or on disk). So after all you might want to port your application. As always use the simpliest solution first. So database queries without any caches. Once you see any problems (performance is below required) just go for optimization. Since you have a fallback solution at hand (cron-jobs + disk fragments) you are at the safe side. But I am in doupt if you really need the markup being cached. Caching the database results and recreate markup sounds more reasonable. You might save you lots of seeking time. But you always know: Only the code / application will tell you! Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:45 An: Tapestry users Betreff: @Cached and caching in general I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? Or is this a pure memory-based cache? I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" themthis is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved. Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds. But maybe the T5 caching mechanism would make all of those low-level tricks redundant? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-m
AW: @Cached and caching in general
You might want to know what tapestry does with your templates. Tapestry reads your template and parses it - only once it changes! So generating two pages (even with different content) just results in using a parsed, preprocessed in memory representation of your template. So tapestry strictly avoids disk-access and parsing in production (when processing all templates on startup is enabled). So there is no need for the older cache it hack. As I mentioned it is easy to play with your own cache implementation. But be carefull about the components you place inside your cache. You know context and event handling. But for displaying 'cached' content it might be an option. If you go ahead and try it you may post your benchmarks. I don't know who has stretched it before but I guess caching is always a hot topic so if you can provide new insides your are welcome. Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 18:15 An: Tapestry users Betreff: AW: @Cached and caching in general > The problem is context I guess. Usally your component depends on lots > of stuff. Parameters, URL, Services, Page-state, component state, > HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables). Original-Nachricht > Datum: Tue, 18 Mar 2008 18:14:28 +0100 > Von: "Filip S. Adamsen" <[EMAIL PROTECTED]> > An: Tapestry users > Betreff: Re: AW: @Cached and caching in general > A factor 100?? C'mon. If, and I stress IF, your application would > benefit that much from this, fine. But Tapestry 5 applications in > general would - I guarantee you - not see such an improvement. > > -Filip > > On 2008-03-18 18:07, Tobias Marx wrote: > > My theory is that such a disk-caching behaviour could speed up Tapestry > applications by factor 100although Tapestry 5 is quite fast. > > > > The template parsing is still quite slow because it uses Velocity and > everything that avoids template parsing would increase the speed a lot. > > > > > > Original-Nachricht > >> Datum: Tue, 18 Mar 2008 18:01:40 +0100 > >> Von: "Martin Kersten" <[EMAIL PROTECTED]> > >> An: "Tapestry users" > >> Betreff: AW: @Cached and caching in general > > > >> @Chached is only used during a single page rendering cycle. It would > not > >> apply to your situation. (as far as I know) > >> > >> Source: > >> http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > >> Your scenario would be implementable using your own component. > >> The component would represent a fragment and read the file (even > >> use a inmemory cache strategy (soft/weakreferences)) and write > >> the ouput directly to stream (or actually the dom tree of your > >> document being returned). > >> > >> Using your own solution enables you to mimic the behavior you talk > about. > >> Another idea would to write / cache only datas needed to render the > tables > >> (e.g. cache only content not markup). Never the less I am in doupt, > >> if such a solution is necessary (dynamically cache results of > >> database queries in memory or on disk). > >> > >> So after all you might want to port your application. As always use > >> the simpliest solution first. So database queries without any caches. > >> Once you see any problems (performance is below required) just go for > >> optimization. Since you have a fallback solution at hand (cron-jobs + > >> disk fragments) you are at the safe side. But I am in doupt if you > >> really need the markup being cached. Caching the database results > >> and recreate markup sounds more reasonable. You might save you lots > >> of seeking time. > >> > >> But you always know: Only the code / application will tell you! > >> > >> > >> Cheers, > >> > >> Martin (Kersten) > >> > >> -Ursprüngliche Nachricht- > >> Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >> Gesendet: Dienstag, 18. März 2008 17:45 > >> An: Tapestry users > >> Betreff: @Cached and caching in general > >> > >> I have not used T5 yet, but would @Cached use the file system for > caching > >> HTML fragments similiar to caching mechanisms in some php frameworks? > >> > >> Or is this a pure memory-based cache? > >> > >> I am thinking about migrating an old PHP application to T5 - it has > really > >> a lot of traffic and any users are logged in at the same time. > >> > >> It is quite a low-level application that is still quite fast due to > cron > >> jobs in the background that generate HTML fragments that are included > to > >> reduce the database-query bottleneck (e.g. grouping/ordering and > sorting of > >> huge tables). > >> > >> Somehow I don't trust Hibernate for high-performance database queries > on > >> huge tables as I think if tables are huge and many people access > it, it > >> will always lead to problems...no matter how good the queries are and > how > >> well you have splitted the data across several tables. > >> > >> So I think the best solution is always to generate HTML fragments in > the > >> background that take a long time and simple "include" themthis is > even > >> quicker then parsing templates when the data is cached. So you save the > time > >> necessary for querying the database plus the time necessary for > processing > >> the templates that are involved. > >> > >
AW: @Cached and caching in general
> The problem is context I guess. Usally your component depends on lots > of stuff. Parameters, URL, Services, Page-state, component state, > HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: "Martin Kersten" <[EMAIL PROTECTED]> An: "Tapestry users" Betreff: AW: @Cached and caching in general @Chached is only used during a single page rendering cycle. It would not apply to your situation. (as far as I know) Source: http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ Your scenario would be implementable using your own component. The component would represent a fragment and read the file (even use a inmemory cache strategy (soft/weakreferences)) and write the ouput directly to stream (or actually the dom tree of your document being returned). Using your own solution enables you to mimic the behavior you talk about. Another idea would to write / cache only datas needed to render the tables (e.g. cache only content not markup). Never the less I am in doupt, if such a solution is necessary (dynamically cache results of database queries in memory or on disk). So after all you might want to port your application. As always use the simpliest solution first. So database queries without any caches. Once you see any problems (performance is below required) just go for optimization. Since you have a fallback solution at hand (cron-jobs + disk fragments) you are at the safe side. But I am in doupt if you really need the markup being cached. Caching the database results and recreate markup sounds more reasonable. You might save you lots of seeking time. But you always know: Only the code / application will tell you! Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:45 An: Tapestry users Betreff: @Cached and caching in general I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? Or is this a pure memory-based cache? I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" themthis is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved. Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds. But maybe the T5 caching mechanism would make all of those low-level tricks redundant? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: @Cached and caching in general
My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht > Datum: Tue, 18 Mar 2008 18:01:40 +0100 > Von: "Martin Kersten" <[EMAIL PROTECTED]> > An: "Tapestry users" > Betreff: AW: @Cached and caching in general > @Chached is only used during a single page rendering cycle. It would not > apply to your situation. (as far as I know) > > Source: > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > > Your scenario would be implementable using your own component. > The component would represent a fragment and read the file (even > use a inmemory cache strategy (soft/weakreferences)) and write > the ouput directly to stream (or actually the dom tree of your > document being returned). > > Using your own solution enables you to mimic the behavior you talk about. > Another idea would to write / cache only datas needed to render the tables > (e.g. cache only content not markup). Never the less I am in doupt, > if such a solution is necessary (dynamically cache results of > database queries in memory or on disk). > > So after all you might want to port your application. As always use > the simpliest solution first. So database queries without any caches. > Once you see any problems (performance is below required) just go for > optimization. Since you have a fallback solution at hand (cron-jobs + > disk fragments) you are at the safe side. But I am in doupt if you > really need the markup being cached. Caching the database results > and recreate markup sounds more reasonable. You might save you lots > of seeking time. > > But you always know: Only the code / application will tell you! > > > Cheers, > > Martin (Kersten) > > -Ursprüngliche Nachricht- > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 18. März 2008 17:45 > An: Tapestry users > Betreff: @Cached and caching in general > > I have not used T5 yet, but would @Cached use the file system for caching > HTML fragments similiar to caching mechanisms in some php frameworks? > > Or is this a pure memory-based cache? > > I am thinking about migrating an old PHP application to T5 - it has really > a lot of traffic and any users are logged in at the same time. > > It is quite a low-level application that is still quite fast due to cron > jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > > Somehow I don't trust Hibernate for high-performance database queries on > huge tables as I think if tables are huge and many people access it, it > will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > > So I think the best solution is always to generate HTML fragments in the > background that take a long time and simple "include" themthis is even > quicker then parsing templates when the data is cached. So you save the time > necessary for querying the database plus the time necessary for processing > the templates that are involved. > > Currently the setup on this application uses one-way database replication > and the cron jobs access the the huge data table on the replicated database > and generate those HTML fragments without disturbing the web-applications > performance. So the main application simply includes those HTML fragments > within milliseconds. > > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: @Cached and caching in general
The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Providing such a low-level cache might sound reasonable but remembering my own requirements lots of days back (2001) the cache depended on a flag system being triggered by distributed actions. If you need your own cache (being driven that way) you might want to create your own component (check out the rendering pipe) My Content to cache Please report your findings. But I am in doupt such a general caching service is needed. But as far as I know Tapestry and its agility, all you need -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:58 An: Tapestry users Betreff: Re: @Cached and caching in general Ok. Thanks...this is what I wanted to know. What about an annotation for "components"/"pages ? @CachedOutput (time=3600) In this case a "component" or "page" would not render itself every time but cache its output to the filesystem (a cache directory). Every hour it would re-generate/refresh its output and this way save lots of performance. Original-Nachricht > Datum: Tue, 18 Mar 2008 17:52:11 +0100 > Von: "Davor Hrg" <[EMAIL PROTECTED]> > An: "Tapestry users" > Betreff: Re: @Cached and caching in general > @Cached is an annotation > that caches method call result per request. > so while page is rendering if multiple pieces of template require that > property it gets called only once... > > Davor Hrg > > On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx <[EMAIL PROTECTED]> wrote: > > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > > > > Or is this a pure memory-based cache? > > > > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > > > > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are > included to reduce the database-query bottleneck (e.g. > grouping/ordering and sorting of huge tables). > > > > Somehow I don't trust Hibernate for high-performance database > > queries > on huge tables as I think if tables are huge and many people > access it, it will always lead to problems...no matter how good the > queries are and how well you have splitted the data across several tables. > > > > So I think the best solution is always to generate HTML fragments > > in > the background that take a long time and simple "include" themthis > is even quicker then parsing templates when the data is cached. So you > save the time necessary for querying the database plus the time > necessary for processing the templates that are involved. > > > > Currently the setup on this application uses one-way database > replication and the cron jobs access the the huge data table on the > replicated database and generate those HTML fragments without > disturbing the web-applications performance. So the main application > simply includes those HTML fragments within milliseconds. > > > > But maybe the T5 caching mechanism would make all of those > > low-level > tricks redundant? > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: @Cached and caching in general
@Chached is only used during a single page rendering cycle. It would not apply to your situation. (as far as I know) Source: http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ Your scenario would be implementable using your own component. The component would represent a fragment and read the file (even use a inmemory cache strategy (soft/weakreferences)) and write the ouput directly to stream (or actually the dom tree of your document being returned). Using your own solution enables you to mimic the behavior you talk about. Another idea would to write / cache only datas needed to render the tables (e.g. cache only content not markup). Never the less I am in doupt, if such a solution is necessary (dynamically cache results of database queries in memory or on disk). So after all you might want to port your application. As always use the simpliest solution first. So database queries without any caches. Once you see any problems (performance is below required) just go for optimization. Since you have a fallback solution at hand (cron-jobs + disk fragments) you are at the safe side. But I am in doupt if you really need the markup being cached. Caching the database results and recreate markup sounds more reasonable. You might save you lots of seeking time. But you always know: Only the code / application will tell you! Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:45 An: Tapestry users Betreff: @Cached and caching in general I have not used T5 yet, but would @Cached use the file system for caching HTML fragments similiar to caching mechanisms in some php frameworks? Or is this a pure memory-based cache? I am thinking about migrating an old PHP application to T5 - it has really a lot of traffic and any users are logged in at the same time. It is quite a low-level application that is still quite fast due to cron jobs in the background that generate HTML fragments that are included to reduce the database-query bottleneck (e.g. grouping/ordering and sorting of huge tables). Somehow I don't trust Hibernate for high-performance database queries on huge tables as I think if tables are huge and many people access it, it will always lead to problems...no matter how good the queries are and how well you have splitted the data across several tables. So I think the best solution is always to generate HTML fragments in the background that take a long time and simple "include" themthis is even quicker then parsing templates when the data is cached. So you save the time necessary for querying the database plus the time necessary for processing the templates that are involved. Currently the setup on this application uses one-way database replication and the cron jobs access the the huge data table on the replicated database and generate those HTML fragments without disturbing the web-applications performance. So the main application simply includes those HTML fragments within milliseconds. But maybe the T5 caching mechanism would make all of those low-level tricks redundant? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
