Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
XSLTProcessor
-
This component's design is intrinsically bad from a cache
perspective: the only way to access validity is through
getTransformerHandlerAndValidity which always creates the
TransformerHandler even if we don't use
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
XSLTProcessor
-
This component's design is intrinsically bad from a cache
perspective: the only way to access validity is through
getTransformerHandlerAndValidity which always creates the
TransformerHandler
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
-
why in hell is use-store to false??? IIRC, it was fist set to true
because the transient store was actually not transient and tried to
serialize compiled XSLTs in the persistant store, which failed
because
Jeremy Quinn wrote:
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
Let's switch it to true an ensure the transient store is really
transient.
+1. Store is checking for Serializable (again, IIRC), which should be
enough.
We turned this on on a production box
On Thursday, October 30, 2003, at 11:42 AM, Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
Let's switch it to true an ensure the transient store is really
transient.
+1. Store is checking for Serializable (again,
Carsten Ziegeler wrote:
While debugging/profiling a very big application for our customer I found out that the current implementation of the TraxTransformer is slowing down caching!
Why? Well, the caching algorithm asks every sitemap component if the cached content is still valid. The
Stefan Seifert wrote:
Wouldn't it be better to extend the validity mechanism?
When the master xslt does not change, the includes does not change either.
It should be possible to use an extended validity object that,
when parsing the xslt for imports/includes is finished, stores
the
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
While debugging/profiling a very big application for our
customer I found out that the current implementation of the
TraxTransformer is slowing down caching!
Why? Well, the caching algorithm asks every sitemap component if
the cached content
Sylvain Wallez wrote:
-1.
If you need the optimisation quickly for your customer, please make a
different class or keep it private until we do the clean refactoring.
I already committed it before I wrote the mail because I think it'S
an important feature - but I can revert it. It's not
On 29.10.2003 10:09, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
-1.
If you need the optimisation quickly for your customer, please make a
different class or keep it private until we do the clean refactoring.
I already committed it before I wrote the mail because I think it'S
an important
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
While debugging/profiling a very big application for our
customer I found out that the current implementation of the
TraxTransformer is slowing down caching!
Why? Well, the caching algorithm asks every
Unico Hommes wrote:
Sylvain Wallez wrote:
We must refactor the XSLTProcessor so that:
- it returns a MultiSourceValidity if needed (see in o.a.c.c.source.impl in scratchpad).
I moved it out into repository block in case anybody was wondering where it went. I moved it with
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
We must refactor the XSLTProcessor so that:
- it returns a MultiSourceValidity if needed (see in
o.a.c.c.source.impl in scratchpad).
I moved it out into repository block in case anybody was
Sylvain Wallez wrote
You know what? I started this refactoring on my HD at the time this
problem was raised, but never had the time to finish it...
Anyway, I agree that refactoring the XSLTProcessor is a way to
go and that with useStore the problem is not that important.
BUT, then
implementation.
Cheers, Alfred.
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 29. Oktober 2003 10:05
To: [EMAIL PROTECTED]
Subject: RE: [IMP] Performance problems with TraxTransformer
Stefan Seifert wrote:
Wouldn't it be better to extend the validity
Nathaniel Alfred wrote:
Checking all dependencies sounds first to be the right thing to do but it can introduce a new performance bottleneck. Just think of a well structured hierarchy of stylesheets stored on a filer, where now the cache validity check requires dozens of NFS-stat calls.
Caching
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Due to this mechanism, each stylesheet is parsed on every request (if
cached content is used or not) which is in most cases unnecessary. As
we didn't use the use-store parameter of the xslt transformer this
is a real performance problem!
Is the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
...
I added a check-includes configuration to
the TraxTransformer. If you set it to false imported stylesheet
are not checked for changes for the caching, but you really feel
the performance difference.
...
PS:
Why? Well, the caching algorithm asks every sitemap
component if the cached content is still valid. The
TraxTransformer answers this question by looking
if the stylesheet has changed since the last use
(time stamp comparison).
So far so good, but you can have imports/includes
in your
19 matches
Mail list logo
