My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100....although 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" <users@tapestry.apache.org> > 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" them....this 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]
