Performance of OPS 3.0 (Beta 3)

Hi,

I am running OPS 3.0 beta3 on Tomcat 5.5.9 with Sun
JSDK 1.5.0_04/Win2000Prof (server VM, Xmx 512) on a
Celeron 1.7 GHz. Right now if I click the BizDocNG
example it takes almost 10 seconds at 100% CPU to
start the overview, then again almost 10 seconds at
100% CPU if I click "Edit". That is really slow. And
I'm using it only myself (1 concurrent user). I think
the performance would be absolutely unacceptable for
multiple concurrent users as systems that use 100% CPU
will decrease in performance proportionally with
number of concurrent users.

I saw that performance is an known issue.

Now the question: What is it that makes it so slow? Is
there room for improvement for 3.0 final or can we
expect to be the performance roughly the same (which
then would be a showstopper for me, sadly)?

Cheers
Michael


       

       
               
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Michael,

Indeed it is unfortunate that performance is an
issue.

My opinion is that it can be improved by writing
a custom epilogue processor.  Currently, the
epilogue does a lot of transformations.  Some of
these could be eliminated, for example, having the
includes for the theme css files be in your
view.xsl file.

The current examples are a very uncluttered
xml/html that better demonstrates the flexibility of
XForms to be adapted to other devices.  I think
this is the right approach, at least for now.

If you know that your application will only be
accessed by browsers, your view.xsl files could
include all kinds of css and JavaScript includes
or even code.  This is especially true of pages
that simply display data, no XForms.  Pipelines
can easily be written that only do one or two
transforms to create the html.  This is my
approach for now -- the XForms pages will be
pretty slow because they will use the epilogue.

Also, this is the kind of application that should
be tuned a bit for memory.  Check your Tomcat
startup settings and give the JRE as much memory
as you can.  OPS does have a caching mechanism.

--Hank
UCSB, California

----- Original Message -----
From: "Michael Mayr" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, September 28, 2005 4:51 AM
Subject: [ops-users] Performance of OPS 3.0 (Beta 3)


--------------------------------------------------------------------------------


>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Michael,

Some parts of the new XForms engine (namely the initialization, which
takes place the first time an XForms page is shown, but not for
subsequent Ajax interactions) have been written using multiple XSLT
transforms in the OPS epilogue. This accounts for most of the current
performance hit you are seeing. We plan to greatly improve this for 3.0
final, by rewriting those XSLT transformations natively. In what measure
peformance will be improved we cannot say yet, but we will do our best!

As a general rule though, you should never use a Celeron for anything
but reading email ;-) Kidding aside, using a modern CPU such as a
Pentium 4 @ ~3 GHz or equivalent is clearly the recommended hardware
platform for OPS.

-Erik

Michael Mayr wrote:

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

nice to hear that there is room for improvement for
3.0 final. Can you give an estimate when 3.0 final
will be released? Is the output of the xforms
initialization phase cacheable so that this
performance hit will only occur for the first user?

Little thought experiment concerning your hardware
recommendations:

My Celeron 1.7 GHz has a Pentium 4 Core but not as
much cache and as far as I remember the FSB (Front
Side Bus) is about 30% slower. I expect a Pentium 4
1.7 GHz to be 50% faster in the best case. So the
recommended Pentium 4 3 GHz will roughly be 3 times
faster than my 1.7 Ghz Celeron. That means I will be
able to serve 3 concurrent users instead 1 with the
same performance I now have. And the user experience
of these 3 concurrent users won't be very pleasing.
But maybe I am aiming at possibly 50 or more
concurrent users. That means it would take 17(!!!)
Pentium 4 with 3 GHz for the same performance. And
that would be dedicated OPS machines in a scenario
where they don't have to run together with other J2EE
apps in a shared company appserver (maybe
unrealistic). And it would cost loads of money.
Scaling with hardware is always the worst thing to
recommend. That should only be seen as a last
resort...

But I know you are working on it, and that is a good
thing.

Cheers
Michael
--- Erik Bruchez <[hidden email]> schrieb:


       

       
               
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Michael Mayr wrote:

 > nice to hear that there is room for improvement for 3.0 final. Can
 > you give an estimate when 3.0 final will be released?

We hope to be able to release by the end of October.

 > Is the output of the xforms initialization phase cacheable so that
 > this performance hit will only occur for the first user?

It may be if the page does not depend on too many variables, like a
submitted XML instance, etc., and you are right, this is an aspect to
look at. But in many cases, the page may be sufficiently dynamic that
caching is not a solution, and in that case improving the processing
time remains necessary.

Note that:

o Except for the XForms NG engine, OPS performance between 2.8 and 3.0
   beta 3 should not have changed for the worse.

o If you don't use XForms, XForms processing is entirely bypassed and
   performance will not take the hit currently required by the XForms
   engine initialization.

o As Hank suggested, you may be able to do some tuning of the
   epilogue. I refer you to this page for documentation about the page
   flow epilogue:

     http://www.orbeon.com/ops/doc/reference-epilogue

o You should be careful NOT to measure performance going through the
   examples portal, which basically generates two full pages each with
   epilogue and some extra processing: once for the example itself,
   once for the enclosing portal page. Your application typically will
   not run through the example portal, of course. A better measure of
   performance consists in bypassing the examples portal. For example,
   the BizDoc NG example is available directly under the path /bizdoc2,
   and the BizDoc Classic example under the path /bizdoc.

 > Little thought experiment concerning your hardware recommendations:
 >
 > My Celeron 1.7 GHz has a Pentium 4 Core but not as much cache and as
 > far as I remember the FSB (Front Side Bus) is about 30% slower. I
 > expect a Pentium 4 1.7 GHz to be 50% faster in the best case. So the
 > recommended Pentium 4 3 GHz will roughly be 3 times faster than my
 > 1.7 Ghz Celeron. That means I will be able to serve 3 concurrent
 > users instead 1 with the same performance I now have. And the user
 > experience of these 3 concurrent users won't be very pleasing.  But
 > maybe I am aiming at possibly 50 or more concurrent users. That
 > means it would take 17(!!!)  Pentium 4 with 3 GHz for the same
 > performance. And that would be dedicated OPS machines in a scenario
 > where they don't have to run together with other J2EE apps in a
 > shared company appserver (maybe unrealistic). And it would cost
 > loads of money.  Scaling with hardware is always the worst thing to
 > recommend. That should only be seen as a last resort...

I am not sure about the exact performance difference between Celeron
and regular P4 (OPS seems to benefit a lot on high memory bandwidth,
for example as of about 2 years ago, Pentium M laptops performed
almost as well as desktop CPUs for OPS processing), but your approach
is of course sound, and I was not suggesting that using a P4 3 GHz
would actually "solve" the performance problem.

So for now we must ask for a little patience until OPS 3.0 final.

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws