cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans-Guenter Stein <Hans-Guenter.St...@siteos.de>
Subject Re: cache and performance
Date Wed, 05 Jul 2000 16:06:50 GMT
Sounds great (since I actually started all these recent caching and performance
threads). Please keep me posted about your code enhancements.

"Kearney, Bryan" wrote:

> We did some performance analysis (WL5.1, Cocoon 1.7.4, with our own
> producer) and found that the Xalan transformation was 70% of time. Our own
> producer was 15%. We have mucked around with the code, and put a cache in
> for the parsed XSL templates. This has taken the time down to 40% for the
> transformation and 40% for our producer (moer acceptable). As soon as we are
> comfortable this works we will post it.
>
> This fix is a flexibility/performance trade off.. but one you may wish to
> make.
>
> -- bk
>
> -----Original Message-----
> From: Henning von Bargen [mailto:H.vonBargen@Triestram-Partner.de]
> Sent: Wednesday, July 05, 2000 12:37 AM
> To: cocoon-users@xml.apache.org
> Subject: AW: cache and performance
>
> > -----Urspr√ľngliche Nachricht-----
> > Von:  Ulrich Mayring [SMTP:ulim@denic.de]
> > Gesendet am:  Dienstag, 4. Juli 2000 17:26
> > An:   cocoon-users@xml.apache.org
> > Betreff:      Re: cache and performance
> >
> > Torsten Curdt wrote:
> > >
> > > Well, the point is - what is a page? Our XML-files stay the same most
> > > of the time, our XSLT-files stay the same.
> > > What changes is the data that comes out of the database that
> > > "enriches" the XML-files. So there is a long way until we can
> > > talk about "a page" and on this way there still some components
> > > that stay the same!!
> >
> > So you don't need to cache pages, but parts of pages. There is no
> > built-in solution to that in cocoon, but you can try playing with the
> > XInclude processor. If you manage to include the dynamic parts, then the
> > static page can be cached. However, if you access a database for the
> > dynamic data, then I would think that most of the processing time is
> > lost in JDBC/database processing. XSLT can be slow, too, but with my
> > apps I have experienced that database access is the bottleneck.
> >
> > Ulrich
> >
> > --
> > Ulrich Mayring
> > DENIC eG, Systementwicklung
>
> I agree with both of you: Caching should be optimized and database access is
> the bottleneck.
> Real-world applications usually display data from 3 or more tables
> (master-detail, descriptions for codes, ...)
> on one single page.
> So there is a lot of (application-specific) tuning possible on the SQL side.
> Decide which is the best method for a given page:
>   - use a single query to join all tables (and optimize this query, too)
>   - split the task into more than one queries on the client (that is,
> Cocoon) side
>   - use perhaps one stored procedure that delivers the results in XML format
>
>     (possible with OAS,mod_owa or owskiller) though post-processing these
> results with XSLT
>     would need additional XML-parsing.
>   - other solutions?
>   - some of the data in the database usually changes seldomly (Stammdaten in
> german)
>     and could be loaded only once a day and used with a taglib
> And, of course, DB login takes a lot of time, so having a connection pool
> should help very much.
> Henning
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org


Mime
View raw message