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 <users@tapestry.apache.org> > 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 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] > > > > --------------------------------------------------------------------- > 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]
