Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 19128 invoked from network); 29 Oct 2003 07:30:14 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 29 Oct 2003 07:30:14 -0000 Received: (qmail 87182 invoked by uid 500); 29 Oct 2003 07:29:48 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 87133 invoked by uid 500); 29 Oct 2003 07:29:47 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 87116 invoked from network); 29 Oct 2003 07:29:47 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 29 Oct 2003 07:29:47 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEkmE-0008US-00 for ; Wed, 29 Oct 2003 08:29:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: dev@cocoon.apache.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEkmC-0008UE-00 for ; Wed, 29 Oct 2003 08:29:56 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEkmC-0004CO-00 for ; Wed, 29 Oct 2003 08:29:56 +0100 From: Sylvain Wallez Subject: Re: [IMP] Performance problems with TraxTransformer Date: Wed, 29 Oct 2003 08:29:58 +0100 Lines: 69 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: fr, en, en-us In-Reply-To: Sender: news Cc: users@cocoon.apache.org X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 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 xslt, so the TraxTransformer checks them as well - and this is done by "parsing" the xslt and looking at all includes/imports. This parsing is done, even when the content is fetched out of the cache. > >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 reparsing always occuring, even if when "use-store" is "true"? I guess not. This was discussed a while ago, and we have here the combination of two bug/deficiencies: 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 these objects are not serializable. Let's switch it to true an ensure the transient store is really transient. 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 it. Combine this with use-store=false, and we end up reparsing the XSL at each call. >As the parsing is very time consuming, delivering a cached content is still "slow". We had figures, where a cached content took 1.5 sec (and producing it from scratch took 1.8 sec). > >With the recent changes we are down below 100ms for delivering the cached content! 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. > >So, you loose a little bit comfort but gain a lot of performance improvements. And if you use it only for production, it shouldn't be a problem anyway. (The default is "as-is") > > This way of solving the problem is hacky as it forces to choose between speed and auto-reload and will often lead people to either not understand why their changes are not taken into account or lead them to choose the "secure" way by setting auto-releoad to false. We must refactor the XSLTProcessor so that: - it returns a MultiSourceValidity if needed (see in o.a.c.c.source.impl in scratchpad). - getting the validity in the transient store is clearly separated from getting the TransformerHandler. >PS: The new feature will be released with 2.1.3 in approx. two weeks. > > -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. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com