On 19 Jul 2001 11:24:01 +1000, Mark Lillywhite wrote:
> >
> > I just run 30 threads of my earlier chapter 15 allelements example on my
> > home machine and noticed that compared to a single thread run, time
> > spent on XSLT increased roughly 6 fold, time spent on build FO tree
> > increased 30 fold, formating 12 fold. Context switches are at 60000 per
> > second level while in FOP, compared to 4000 per second while in Xalan.
> >
> In unmodified FOP, input from the source FO document occurs entirely at
> the beginning of the FOP run, and output entirely at the end. Therefore,
> the largest part of FOP processing occurs entirely in-memory and is
> therefore CPU bound. If you run 30 CPU bound threads concurrently on a
> machine with less than 30 CPUs then you are going to get degraded
> performance.
That's exactly what we observed. Unfortunately, in the servlet world,
multi-threading is the norm. Not so much to distribute the load as to
handle concurrent requests. I simply cannot queue up all the requests
and process then one at a time.
The question then becomes, is there room for improvements. From what
I've heard so far, the answer is yes. Replacing inefficient JDK 1.1
always synchronized data structures, streamline the processing model,
find ways to reduce object creation and garbage collection, seems to be
the key.
> When you say 6, 30 and 12 "fold", I assume you mean times?
Yes. But I have to prefix that with 'uncontrolled unscientific
unofficial pseudo-benchmark on a home machine'. Don't read too much
into it.
> AFAIK,
> processing time on a single CPU machine with a CPU bound thread running
> with 29 other concurrent CPU bound threads *should* take 30 times
> longer, because it's executing 30x the instructions. If the XSLT and the
> formatting are doing I/O then these parts of the system will benefit
> from threading because the JVM can make progress during IO waits. I'm
> actually surprised that the numbers aren't much higher, but perhaps you
> have SMP.
Following suggestions from another post in the thread, we tried Saxon in
place of Xalan, and achieved noticeable speedups. And yes, Saxon is
picky! I'll share some numbers later.
> Anyway, I'm not sure if my analysis is entirely correct here but none of
> this seems particularly surprising to me, and doesn't indicate any
> problems with FOP processing per se.
It raises a question about the suitability of using FOP in a servlet
environment. We certainly learned what is and is not achievable with
today's FOP. And we'll regulate its use in a way that won't flatline
the servers.
> Of course there is a lot I don't know about FOP so maybe someone can
> explain this to me.
In another post Mark wrote:
>
> With my changes to FOP I can process tens of thousands of pages of
> XML:FO in only a few Mb of heap. I have asked for testers but so far
> noone has responded... this sounds like an ideal environment in
I'll volunteer to test. Email me at [EMAIL PROTECTED]
--
Weiqi Gao
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
