cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo F. Ochoa" <moc...@ieee.org>
Subject RE: cache and performance
Date Wed, 05 Jul 2000 14:36:01 GMT

> -----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
[>]  OWSKiller was renamed DB Prism, and it include an XSPConnection Manager logicsheet
based on Ricardo code of XSPConnection Manager.
This logicsheet is in DB Prism distributions 1.0.0-production, check at http://www.plenix.com/dbprism/
for details and there is demo on line at http://yarara.exa.unicen.edu.ar/xsl/index.xml?producer=file

    [>]  This connection logic sheet reuses DB Prism connection from the ResourceManager
and is possible to interact with transaction of DB Prism stored procedures. 
[>]  DB Prism also includes HeaderProcessor to permit reject invalid login or ask to the
user dynamic username/password.
    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
[>]  Best regards, Marcelo. 
Mime
View raw message