Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: Fw: Cocoon 2 RC2 performance disappointment
From: =?ISO-8859-1?Q?S=E9rgio?= Carvalho <sergio.carvalho@acm.org>
To: cocoon-dev@xml.apache.org
In-Reply-To: <00a601c17458$2b3ce640$ac3bfb3e@zeewolde>
References: <00a601c17458$2b3ce640$ac3bfb3e@zeewolde>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 23 Nov 2001 21:27:07 +0000
Message-Id: <1006550827.985.6.camel@khazunga>
Mime-Version: 1.0

My biggest pitfalls when writing a large-scale C2 site:
 1) Using <xsl:for-each>. This XSL construct forces the XSL transformer
to what for the whole XML document before moving to the next
instruction. 
 2) Not using DB connection-pooling (yeah, yeah, supid mistake ;-)
 3) Having the object pools so large that the server ran out of physical
memory and started swapping.

Hope it helps


On Fri, 2001-11-23 at 19:50, Michael Homeijer wrote:
> ----- Original Message -----
> From: "Michael Homeijer" <m.homeijer@hccnet.nl>
> To: <cocoon-dev@xml.apache.org>
> Sent: Friday, November 23, 2001 8:38 PM
> Subject: Cocoon 2 RC2 performance disappointment
> 
> 
> > Hi,
> >
> > We built a site using Cocoon 1. Whe are now in the process of scaling the
> > hardware so it can handle the requested amount of users.
> >
> > Next we started a project to perform migration to Cocoon 2. I think we use
> > all mechanisms (at least the ones I know) to create a site that performs
> > well. But... under heavy load, the performance of the Cocoon 1 site
> remains
> > stable (slow but stable) and the Cocoon 2 site collapses. The initial
> > performance of the Cocoon 2 site is higher, but under "heavy load", it
> will
> > not do very much anymore.
> >
> > Mechanisms we used:
> > - Split pages in multiple parts based on caching posibilities. Ie. parts
> > that can use the same cache strategies (ie same key and validity) are
> > grouped together.
> > - The parts that can be cached are also translated to HTML using XSL as
> much
> > as possible.
> > - The XSL files are kept as small as possible. We tried to minimize the
> > amount of templates (initially there were about 60 templates).
> >
> > This site should be our showcase and one of the most complex ones we will
> > build because of the very dynamic nature of the site and high amount of
> > personalisation based on countries, companies and user profiles. Most
> pages
> > contain at least three to four calls to session beans.
> >
> > A quote from a report about the migration:
> > "The expected performance improvement was not confirmed by the obtained
> > results. Performance of the c2 site was dramatically lower than of the c1
> > site. In 10 minutes, the c1 site was able to process 16283 catalogue
> > requests and send out 6MB of pages, the c2 site managed 1011 requests and
> > 400 kB."
> >
> > I could use some help tuning this site. Any suggestions are welcome.
> >
> > TIA,
> > Michael Homeijer
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
-- 
Sergio Carvalho
---------------
sergio.carvalho@acm.org

If at first you don't succeed, skydiving is not for you


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org