Re: @Cached and caching in general
Tobias Marx wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Just an example : you are in a loop (or grid or a beaneditor any other looping component) and you get the current value of an object, for the current iteration. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. Original-Nachricht Datum: Tue, 25 Mar 2008 13:33:19 +0100 Von: Francois Armand [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general Tobias Marx wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Just an example : you are in a loop (or grid or a beaneditor any other looping component) and you get the current value of an object, for the current iteration. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - 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: @Cached and caching in general
[EMAIL PROTECTED] wrote: Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. That means that if forbid the use of loop in page (for example, a loop through all the high-level widgets of the page) , or at least that the default behaviour for component's or for page's method is not the same... In my opinion, it looks like to be very error prone, with things that just don't work as expected. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
caching every method by default is definitely too error prone, and unexpected for most people. On Tue, Mar 25, 2008 at 3:23 PM, Francois Armand [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. That means that if forbid the use of loop in page (for example, a loop through all the high-level widgets of the page) , or at least that the default behaviour for component's or for page's method is not the same... In my opinion, it looks like to be very error prone, with things that just don't work as expected. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - 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: @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]
Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually built or
retrieved only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.
}
during a request of a single thread you can call
buildExpensiveHtmlFragment() as many times as you want with a full
confidence that the work to build it would be performed only once.
When you refresh the page, the build will be invoked once again (but
once only).
-adam
On Tue, Mar 18, 2008 at 11:44 AM, 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]
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 users@tapestry.apache.org 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]
Re: @Cached and caching in general
Tapestry already does some caching on invariant properties, and when it
doesn't the overhead of actually reading the property again is
negligible unless it result in a database query etc. Also, I have plenty
of pages where properties change while rendering the page.
So, no. It wouldn't be useful.
-Filip
On 2008-03-18 18:01, Tobias Marx wrote:
Wouldn't it be useful to make the @Cache annotation the default annotation
for all methods?
I can not imagine a case where it would make sense that during the rendering of
a page returns different results...
Original-Nachricht
Datum: Tue, 18 Mar 2008 11:53:09 -0500
Von: Adam Zimowski [EMAIL PROTECTED]
An: Tapestry users users@tapestry.apache.org
Betreff: Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually built or
retrieved only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.
}
during a request of a single thread you can call
buildExpensiveHtmlFragment() as many times as you want with a full
confidence that the work to build it would be performed only once.
When you refresh the page, the build will be invoked once again (but
once only).
-adam
On Tue, Mar 18, 2008 at 11:44 AM, 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]
Re: @Cached and caching in general
Wouldn't it be useful to make the @Cache annotation the default annotation
for all methods?
I can not imagine a case where it would make sense that during the rendering of
a page returns different results...
Original-Nachricht
Datum: Tue, 18 Mar 2008 11:53:09 -0500
Von: Adam Zimowski [EMAIL PROTECTED]
An: Tapestry users users@tapestry.apache.org
Betreff: Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually built or
retrieved only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.
}
during a request of a single thread you can call
buildExpensiveHtmlFragment() as many times as you want with a full
confidence that the work to build it would be performed only once.
When you refresh the page, the build will be invoked once again (but
once only).
-adam
On Tue, Mar 18, 2008 at 11:44 AM, 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]
RE: @Cached and caching in general
Hibernate makes it easy to do some really interesting things without a great deal of thought. Any time you start working with large data sets you have to think carefully about what Hibernate is doing on your behalf - like the inner loop example. For some reporting tasks, you might want to use Hibernate to generate a recordset from raw SQL. For other cases, changing a fetch strategy from LAZY to EAGER will address the performance issues. A substitute for your existing caching, depending on memory requirements, might be to implement a results-cache as a service within your Tapestry app. Mimic what is done currently, but perhaps schedule refreshes with Quartz and keep it within the same app. Jonathan -Original Message- From: Tobias Marx [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 1:35 PM To: Tapestry users Subject: 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 users@tapestry.apache.org 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
Nope. It's dangerous stuff that should be used with care.
On Tue, Mar 18, 2008 at 10:01 AM, Tobias Marx [EMAIL PROTECTED] wrote:
Wouldn't it be useful to make the @Cache annotation the default annotation
for all methods?
I can not imagine a case where it would make sense that during the rendering
of a page returns different results...
Original-Nachricht
Datum: Tue, 18 Mar 2008 11:53:09 -0500
Von: Adam Zimowski [EMAIL PROTECTED]
An: Tapestry users users@tapestry.apache.org
Betreff: Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a
method which has @Cache annotation will get actually built or
retrieved only once - but only once per http request. So if you're
building an expensive HTML fragment:
@Cached
public String buildExpensiveHtmlFragment() {
//.
}
during a request of a single thread you can call
buildExpensiveHtmlFragment() as many times as you want with a full
confidence that the work to build it would be performed only once.
When you refresh the page, the build will be invoked once again (but
once only).
-adam
On Tue, Mar 18, 2008 at 11:44 AM, 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]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
