Return-Path: 
 <cocoon-dev-return-37882-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 84788 invoked by uid 500); 7 Mar 2003 15:40:25 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 84694 invoked from network); 7 Mar 2003 15:40:24 -0000
Received: from vern.chem.tu-berlin.de (130.149.66.116)
  by daedalus.apache.org with SMTP; 7 Mar 2003 15:40:24 -0000
Received: from vern.chem.tu-berlin.de (localhost [127.0.0.1])
	by vern.chem.tu-berlin.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id
 h27FeMcM029010
	for <cocoon-dev@xml.apache.org>; Fri, 7 Mar 2003 16:40:23 +0100
Received: from localhost (stephan@localhost)
	by vern.chem.tu-berlin.de (8.12.3/8.12.3/Submit) with ESMTP id h27FeLJ1029007
	for <cocoon-dev@xml.apache.org>; Fri, 7 Mar 2003 16:40:22 +0100
X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing
 -bs
Date: Fri, 7 Mar 2003 16:40:21 +0100 (CET)
From: Stephan Michels <stephan@apache.org>
X-X-Sender: stephan@vern.chem.tu-berlin.de
To: cocoon-dev@xml.apache.org
Subject: Re: XSLTProcessor and Store was: Performance leak
In-Reply-To: <3E68B10F.4020907@anyware-tech.com>
Message-ID: <Pine.LNX.4.44.0303071634290.27246-100000@vern.chem.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


On Fri, 7 Mar 2003, Sylvain Wallez wrote:

> Stephan Michels wrote:
>
> >On Thu, 6 Mar 2003, Stephan Michels wrote:
> >
> >>On Thu, 6 Mar 2003, Carsten Ziegeler wrote:
> >>
> >>>Stephan Michels wrote:
> >>>
> >>>>I do some profiling today, and wondering why the XSLT transformer
> >>>>burns performance like hell in setup(). After some debugging I noticed
> >>>>that the XSLT transformer create a complete new template/handler for
> >>>>each call of setup(), that because the parameter 'use-store' in
> >>>>cocoon.xconf is set to 'false' per default.
> >>>>
> >>>>After setting this parameter to 'true', the performance increased
> >>>>dramatically.
> >>>>
> >>>>So, is there a reason, why this parameter is set to 'false'? When
> >>>>not, I would change it to 'true'.
> >>>>
> >>>There was a reason: a memory leak :) So you can change from performance
> >>>to memory leak. This leak was at least in last Xalan versions, I never
> >>>tested if it is in the latest, so perhaps this is fixed now.
> >>>If not, you can run into serious memory problems.
> >>>
> >>Doh! ;-) I'll make some longtime stability tests, to verify this. The
> >>memory leak should also occur if you use the store, except if you forget
> >>to remove the entries. At the moment, the concept of the XSLTC(and other)
> >>doesn't make any sense, because you compile all used stylesheets for
> >>every request :-/
> >
> >I got NotSerializableException, if I stop the container. This remind
> >with my problems with LexicalTransformer. I solved this problem
> >using own writeObject() and readObject() methods, but the
> >XSLTProcessorImpl using Object[] instances. I also don't know why this
> >array isn't serializable, perhaps the Templates class isn't serializable.
> >
> >Yesterday I measured a performance enhancement by the factor 20x .
> >Before each request took 2000-5000ms, which was untenable. After
> >setting this option, each request took 50-100ms(cached).
> >
> >Perhaps you have an idea, where the problem lie on?
> >
>
> The problem, I think, comes from the fact that XSLTProcessor uses the
> transient store to store Templates, and that the <transient-store> in
> cocoon.xconf has the <parameter name="use-persistent-cache" value="true"/>.
>
> So we actually have a transient store that persists its contents to disk !!!

This is okay, if it's only persists in dispose().

But a simple (object instanceof java.io.Serializable) due to
checkSerializable() seems to be not enough to test if a object
is serializable.

:-/ Stephan Michels.