You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "T.Pospisek's MailLists" <tp...@spin.ch> on 2001/01/19 10:35:16 UTC
Cocoon configuration performance comparison?
Hi all,
has anybody made performance tests with Cocoon together with various
configurations, servlet engines and XSL transformers?
We have been runing a live Cocoon site for quite a while, but have been
forced to pull the plug due to response delays getting tooooooooooooo
long (several couples of seconds) and are generating everything offline
and just copying over the generated pages to our online site now. We're a
low traffic site btw - we've got a 40 hits/hour average.
We'd like to know whether someone has made some performance test with
different setups/configurations/software combinations and what the
aproximate relative gains are, i.e. if there's a relevant speedup to
be expected with the hope to get our site into live mode again.
I've already heard that XT seems to be a lot faster than JXalan, but
that it doesn't seem to be very compatible. *How much* faster is it?
Our server's got the following setup:
- Intel Pentium 233 MHz, 128M RAM, 128M swap
- network connectivity is not a problem
- Linux 2.2.18
- Debian woody/testing
- Apache 1.3.9
- Sun's JRE/jdk1.1.8
- Cocoon 1.8
- jserv1.2 ??
- xalan_1_2_D02.jar
- xerces_1_2.jar
We're runing jserv with the following parameters (if we ommit them, we're
geting out of memory errors). Everything else is default:
* /etc/jserv/jserv.properties:
wrapper.bin.parameters=-ms64m -mx128m -ss500k -oss1m
Judging by "top" the server itself never seemed to suffer neither
performance problems nor memory problems.
I guess this might be interesting to other people as well...
*t
----------------------------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------
Re: Cocoon configuration performance comparison?
Posted by Paul Russell <pa...@luminas.co.uk>.
* T.Pospisek's MailLists (tpo2@spin.ch) wrote :
> Difficult to say:
> * when apache is serving static html pages, we get pretty much instant
> replies. So neither apache, nor disc-IO can be the bottleneck, since
> apache is not caching pages in memory by itself.
Right.
> * if serving pages through Cocoon, I can see Java eat some ressources
> (~35% CPU) for half or a second a then drop down to pretty much zero
> again. All this time through swap usage is staying the same, that means
> that the system is not swaping out stuff or in other words it's probably
> not a memory issue.
Yep.
> * but even if java ressource usage is back to zero again, it still takes
> several seconds for the page to appear. The performance infos on the
> generated pages will typically say something like "page generated by
> Cocoon in 1350ms" or 500ms or something.
Owch. okay, that's longer than I would hope, and tends to indicate that
the cache isn't working.
> * To me it looks like it's the servlet engine/java who is taking an
> eternity to:
> a) initialise (whatever that means, I've got no clue of the inner
> working of that stuff)
Possibly, but I wouldn't imagine so. Servlet engines are designed to be
scalable -- first time requests are slow, but thereafter it should get
faster and faster.
> b) to move the output over to apache so that it can drop it to the tcp
> stack.
Again, I wouldn't have thought so. Have you tried talking direct to your
servlet engine to remove apache from the equation?
> > This is not an official statement or order.
> This email is neither official nor inofficial. It's not even guaranteed
> that it'd be fit for any mailer nor that it really is an email. If there's
> a semantic meaning to the characters written above, that's completely your
> own interpretation and has no direct link to any real or imaginary
> expressed meaning on my part. And even if it had, to assume it's me who
> wrote it might be wrong.
Rofl! Sorry; the lawyers made me do it. :)
Paul.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: Cocoon configuration performance comparison?
Posted by Berin Loritsch <bl...@apache.org>.
Paul Russell wrote:
> * T.Pospisek's MailLists (tpo2@spin.ch) wrote :
>
>
>> On Fri, 19 Jan 2001, Paul Russell wrote:
>
>>
>>> Are the documents very large?
>
>>
>> The average size of a XML document is about 3KB, the average of the
>
>> resulting HTML doc is about 5KB. During the XSL transformation (which is
>
>> quite linear btw. ... see http://sourcepole.com/sources/software/sp.xsl/
>
>> for the XSL source) the navigation bar is included per
>
>> <xsl:apply-templates select="document($navigation-bar)" ...>.
>
>
>
> Hm.. I must admit, I've never used the 'document' function in Xalan. It
>
> may be that it's this which is causing the delay. Worth trying without
>
> it, just to see if that improves things?
Actually, this is the _fastest_ way to include an external resource into
the pages. Also, the delay is marginal at best. Xalan reads ALL associated
sources (XSL, included XML, etc) so that it builds the complete transformer
object that will be used to parse. The object creation time is marginally
longer (not that much, though), but no difference in actual use time.
Re: Link encoding & LinkEncodingProcessor
Posted by Ulrich Mayring <ul...@denic.de>.
I-Chung Young wrote:
>
> You could, however, write your own processor that perform URL.encode()
URLEncoder.encode("String")
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Link encoding & LinkEncodingProcessor
Posted by I-Chung Young <ic...@puma.mt.att.com>.
Hi,
> I have never used other processors after XSLT transformation. Is it
> possible?
Yes.
> Can LinkEncoderProcessor encode links after XSLT transformation?
Yes.
> I have some links, that I must encode in the XSL stylesheet (they are
> generated with XSL).
>
> And, where I can read how does this processor work?
> E.g., I have a link: "link.xml?param=1&enc_param=page.xml?param=2"
> and want it to be: link.xml?param=1&enc_param=page.xml%3Fparam%3D2
>
> Is it possible?
I'm afraid LinkEncodeingProcessor is not what you want. It is used
for encoding session id into URL (if needed) (using servlet API
response.encodeURL()). It only search for "action" and "href" tag
to perform this. What you need is URL.encode(). I think this
should be processed by the page generates the URL before XSLT.
As the link in your example, not all "=" need to be encoded to "%3D".
You could, however, write your own processor that perform URL.encode()
on your own special tag(s).
Thanks.
------------
I-Chung Young
Link encoding & LinkEncodingProcessor
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi, Cocooners!
I have never used other processors after XSLT transformation. Is it
possible?
Can LinkEncoderProcessor encode links after XSLT transformation?
I have some links, that I must encode in the XSL stylesheet (they are
generated with XSL).
And, where I can read how does this processor work?
E.g., I have a link: "link.xml?param=1&enc_param=page.xml?param=2"
and want it to be: link.xml?param=1&enc_param=page.xml%3Fparam%3D2
Is it possible?
Thanks.
Regards,
Konstantin Piroumian.
Re: Cocoon configuration performance comparison?
Posted by "T.Pospisek's MailLists" <tp...@spin.ch>.
On Fri, 19 Jan 2001, Paul Russell wrote:
> > > Judging by "top" the server itself never seemed to suffer neither
> > > performance problems nor memory problems.
>
> Is Cocoon eating processor time when it's serving requests? The problem
> you're having smacks of a IO bound delay, to be honest.
Difficult to say:
* when apache is serving static html pages, we get pretty much instant
replies. So neither apache, nor disc-IO can be the bottleneck, since
apache is not caching pages in memory by itself.
* if serving pages through Cocoon, I can see Java eat some ressources
(~35% CPU) for half or a second a then drop down to pretty much zero
again. All this time through swap usage is staying the same, that means
that the system is not swaping out stuff or in other words it's probably
not a memory issue.
* but even if java ressource usage is back to zero again, it still takes
several seconds for the page to appear. The performance infos on the
generated pages will typically say something like "page generated by
Cocoon in 1350ms" or 500ms or something.
* To me it looks like it's the servlet engine/java who is taking an
eternity to:
a) initialise (whatever that means, I've got no clue of the inner
working of that stuff)
b) to move the output over to apache so that it can drop it to the tcp
stack.
Well ... wild guesses.
> This is not an official statement or order.
This email is neither official nor inofficial. It's not even guaranteed
that it'd be fit for any mailer nor that it really is an email. If there's
a semantic meaning to the characters written above, that's completely your
own interpretation and has no direct link to any real or imaginary
expressed meaning on my part. And even if it had, to assume it's me who
wrote it might be wrong.
*t (say who?)
----------------------------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------
Re: Cocoon configuration performance comparison?
Posted by Paul Russell <pa...@luminas.co.uk>.
* T.Pospisek's MailLists (tpo2@spin.ch) wrote :
> On Fri, 19 Jan 2001, Paul Russell wrote:
> > Are the documents very large?
>
> The average size of a XML document is about 3KB, the average of the
> resulting HTML doc is about 5KB. During the XSL transformation (which is
> quite linear btw. ... see http://sourcepole.com/sources/software/sp.xsl/
> for the XSL source) the navigation bar is included per
> <xsl:apply-templates select="document($navigation-bar)" ...>.
Hm.. I must admit, I've never used the 'document' function in Xalan. It
may be that it's this which is causing the delay. Worth trying without
it, just to see if that improves things?
>
> > Does the machine have enough RAM and a sensible processor?
> Quoting from my posting:
> > - Intel Pentium 233 MHz, 128M RAM, 128M swap
> > - network connectivity is not a problem
> > - Linux 2.2.18
> > - Debian woody/testing
> > - Apache 1.3.9
> > - Sun's JRE/jdk1.1.8
> > - Cocoon 1.8
> > - jserv1.2 ??
> > - xalan_1_2_D02.jar
> > - xerces_1_2.jar
Okay. Not overly powerful, but none the less, I would've thought it
would be faster than you mentioned.
> > We're runing jserv with the following parameters (if we ommit them,
> > we're geting out of memory errors). Everything else is default:
> > * /etc/jserv/jserv.properties:
> > wrapper.bin.parameters=-ms64m -mx128m -ss500k -oss1m
Looks fine.
> > Judging by "top" the server itself never seemed to suffer neither
> > performance problems nor memory problems.
Is Cocoon eating processor time when it's serving requests? The problem
you're having smacks of a IO bound delay, to be honest.
Sorry I can't be more help :/
Paul.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: Cocoon configuration performance comparison?
Posted by Berin Loritsch <bl...@apache.org>.
T.Pospisek's MailLists wrote:
> On Fri, 19 Jan 2001, Paul Russell wrote:
>
>> Our server's got the following setup:
>
>>
>
>> - Intel Pentium 233 MHz, 128M RAM, 128M swap
>
>> - network connectivity is not a problem
>
>> - Linux 2.2.18
>
>> - Debian woody/testing
>
>> - Apache 1.3.9
>
>> - Sun's JRE/jdk1.1.8
>
>> - Cocoon 1.8
>
>> - jserv1.2 ??
>
>> - xalan_1_2_D02.jar
>
>> - xerces_1_2.jar
Memory always helps. 128 MB should be considered the minimum as the
actual usage of the servlet container is ~30 MB but depending on the
site can actually grow upwards of 64 MB, and the OS needs some breathing
room.
The Intel Pentium 233 could definitely be improved. I would place the
processor you are using at the bottom of the usable spectrum. I convinced
my company not to use the 90 MHz pentiums we were originally using for
the web site.
Try upgrading your JDK. If you can get a HotSpot Server java runtime
for Linux do it. The speedup is worth it. Also if you _have_ to remain
at JDK 1.1.x, try the IBM JDK--it is also faster than Sun's.
Unless you are passing HTTP parameters to XSLT, I would highly recommend
using XT. It is almost twice as fast, and alot more light weight.
>
>>
>
>> We're runing jserv with the following parameters (if we ommit them,
>
>> we're geting out of memory errors). Everything else is default:
>
>>
>
>> * /etc/jserv/jserv.properties:
>
>> wrapper.bin.parameters=-ms64m -mx128m -ss500k -oss1m
I usually match the VM memory to my physical memory as a general rule
of thumb. We have a server with 512 MB RAM, and it does well ;P.
>> Judging by "top" the server itself never seemed to suffer neither
>
>> performance problems nor memory problems.
Performance really can't be measured by top. Check out how much of the
processor's time is being used during a page transformation, then check
out how much room you have in RAM. If the processor is always being
pegged for every page transform, then you have a candidate for improvement.
If you are close to your VM memory settings, then you could use more
RAM.
Keep in mind that eventually the cache is invalidated. Every first access
is generally slower. Is your site for the most part static? If so,
then we need to look at how to set the cache invalidation times. If your
site changed very little (no dynamic elements), and you had sufficient
traffic, you would never see the page have to reload itself into cache.
If you have lower traffic than what the cache invalidation timer is set for,
then you will always get the page read from disk. I don't know if this is
a parameterized setting, but it probably should be.
Re: Cocoon configuration performance comparison?
Posted by "T.Pospisek's MailLists" <tp...@spin.ch>.
On Fri, 19 Jan 2001, Paul Russell wrote:
> * T.Pospisek's MailLists (tpo2@spin.ch) wrote :
> > We have been runing a live Cocoon site for quite a while, but have been
> > forced to pull the plug due to response delays getting tooooooooooooo
> > long (several couples of seconds) and are generating everything offline
> > and just copying over the generated pages to our online site now. We're a
> > low traffic site btw - we've got a 40 hits/hour average.
>
> That is deeply worrying. What type of content are you generating?
xsl(XML) -> HTML
> Do you have caching enabled?
Yes, I sure hope so. From /etc/cocoon/cocoon.properties:
##########################################
# Cache Managers #
##########################################
# the default cache
cache = org.apache.cocoon.cache.CocoonCache
# disable page caching
#cache = org.apache.cocoon.cache.NoCache
> Are the documents very large?
The average size of a XML document is about 3KB, the average of the
resulting HTML doc is about 5KB. During the XSL transformation (which is
quite linear btw. ... see http://sourcepole.com/sources/software/sp.xsl/
for the XSL source) the navigation bar is included per
<xsl:apply-templates select="document($navigation-bar)" ...>.
> Does the machine have enough RAM and a sensible processor?
Quoting from my posting:
On Fri, 19 Jan 2001, T.Pospisek's MailLists wrote:
> Our server's got the following setup:
>
> - Intel Pentium 233 MHz, 128M RAM, 128M swap
> - network connectivity is not a problem
> - Linux 2.2.18
> - Debian woody/testing
> - Apache 1.3.9
> - Sun's JRE/jdk1.1.8
> - Cocoon 1.8
> - jserv1.2 ??
> - xalan_1_2_D02.jar
> - xerces_1_2.jar
>
> We're runing jserv with the following parameters (if we ommit them,
> we're geting out of memory errors). Everything else is default:
>
> * /etc/jserv/jserv.properties:
> wrapper.bin.parameters=-ms64m -mx128m -ss500k -oss1m
>
> Judging by "top" the server itself never seemed to suffer neither
> performance problems nor memory problems.
Any ideas?
*t
----------------------------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------
Re: Cocoon configuration performance comparison?
Posted by Paul Russell <pa...@luminas.co.uk>.
* T.Pospisek's MailLists (tpo2@spin.ch) wrote :
> We have been runing a live Cocoon site for quite a while, but have been
> forced to pull the plug due to response delays getting tooooooooooooo
> long (several couples of seconds) and are generating everything offline
> and just copying over the generated pages to our online site now. We're a
> low traffic site btw - we've got a 40 hits/hour average.
That is deeply worrying. What type of content are you generating? Do you
have caching enabled? Are the documents very large? Does the machine
have enough RAM and a sensible processor?
Paul
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk