Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: =?us-ascii?Q?Jorn_Heid?= <heid@fh-heilbronn.de>
To: <cocoon-dev@xml.apache.org>
Subject: AW: [Fwd: Cocoon 2.0 Scalability Disappointment]
Date: Sat, 1 Dec 2001 15:35:39 +0100
Message-ID: <COEBLMNNEMANKDIDOLBFCEAPCEAA.heid@fh-heilbronn.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3C0830A9.4301AF89@apache.org>
Importance: Normal

If incremental processing is disabled (the default) Xalan fires the SAX
events after all transformations have been done.
Under heavy load this can cause great memory usage I guess.
I'm not sure about that. Just a hint.

JOERN

-----Ursprungliche Nachricht-----
Von: Stefano Mazzocchi [mailto:stefano@apache.org]
Gesendet: Samstag, 1. Dezember 2001 02:22
An: Apache Cocoon
Betreff: [Fwd: Cocoon 2.0 Scalability Disappointment]


Paul Brown wrote:
>
> Stefano --
>
> Are you using Xalan J2.2.Dx within Cocoon?  If so, that may account for
it.
> Depending on the application, we've observed SIGNIFICANT performance
> problems with Xalan J2.2.Dx, especially where a transition DOM<->DTM
occurs.

I'm not the one who made the tests.

Maybe this is useful for others.

>         -- Paul
>
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: Friday, November 30, 2001 11:38 AM
> > To: Apache Cocoon
> > Cc: Michael Homeijer
> > Subject: Cocoon 2.0 Scalability Disappointment
> >
> >
> > Michael told me privately the numbers that he has been experiencing
> > along with a description of his environment and I now agree with him, we
> > have a serious scalability problem.
> >
> > He refers to 2.0RC2 but since nothing that could improve performance
> > changed between 2.0 and 2.0RC2, I think it's still up there.
> >
> > For "serious", I mean something important that should be fixed ASAP,
> > otherwise, Cocoon 2.0 will rarely have any use in high-load
> > environments.
> >
> > The numbers say, more or less, than the same functionality ported from
> > Cocoon 1.8.2 to Cocoon 2.0RC2 resulted in 20 times slower performance!
> >
> > Yes, guys, we're not talking about 20% slower but 2000% slower.
> >
> > WAIT, STOP, SIT DOWN!
> >
> > Before you rush to your boss to tell that Cocoon 2.0 sucks and you
> > shouldn't place your million-dollars worth project on it, let me explain
> > what I believe the problem is.
> >
> > 1) their Cocoon 1.8.2 application has been up for a long time and they
> > carefully tuned the system for it. Their Cocoon 2.0RC2 version is an
> > early implementation.
> >
> > 2) they admit the Cocoon 2.0 cache system is likely to provide huge
> > benefits for them, but they are not sure they are using it properly.
> >
> > 3) they don't use a transparent proxy on top so the Cocoon cache is
> > continously stressed.
> >
> > 4) they report much better "perceived" performance on a single browsing
> > experience: this seems to show that Cocoon 2.0 isn't slow by itself, but
> > there is an hidden bottleneck someplace.
> >
> > 5) they use XSP. I'm aware of performance issues with XSP load and
> > execution under heavy load (some forgotten locking or synchronized
> > method?). This is the place where I'd concentrate profiling effort.
> >
> > Net Result: I think Cocoon 2.0, as it stands, doesn't scale, but the
> > data provided it's not sufficient to understand *what* slows Cocoon
> > down.
> >
> > Michael, I'd love if you guys could perform some more load tests for us:
> >
> > 1) disable logging. If log is DEBUG, it could generate Gigabytes of
> > information and disks could become the bottleneck.
> >
> > [I think log might be the bottleneck]
> >
> > 2) disable resource reloading. Same as above, the disk I/O system could
> > become the bottleneck.
> >
> > 3) try to come up with some logarithmic stress tests: 1 req/sec, 2
> > req/sec, 4 req/sec, 8, 16, 32, 64, until your machines saturate.
> >
> > 4) turn the cache off/on. [this, compared to the logaritmic approach
> > should give us information on the caching system]
> >
> > 5) try to get the generated source code of one of your XSP, compile it
> > as a generator and use it as a normal generator instead. [this should
> > remove the XSP loading/handling phase]
> >
> > With this data we will know where the problem is and if it really
> > resides in Cocoon.
> >
> > --
> > Stefano Mazzocchi      One must still have chaos in oneself to be
> >                           able to give birth to a dancing star.
> > <stefano@apache.org>                             Friedrich Nietzsche
> > --------------------------------------------------------------------
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >


--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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


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