cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning von Bargen <>
Subject AW: cache and performance
Date Wed, 05 Jul 2000 06:37:16 GMT
> -----Urspr√ľngliche Nachricht-----
> Von:	Ulrich Mayring []
> Gesendet am:	Dienstag, 4. Juli 2000 17:26
> An:
> 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
    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.

View raw message