Re: [xep-support] Performance and synchronization

From: Irv Salisbury III <irv@dotech.com>
Date: Fri Apr 22 2005 - 14:20:38 PDT

The load balancer I am using now makes everything run smoothly. We have
to enter QA on Monday, so I won't have time to get these exact details
for you right now. I was thinking of just coding up a test case that
just crams tons of xsl:fo documents at renderx, and hopefully I will get
to that soon.

On a side note, some people on this list did reply to me privately and
had told me they were seeing the same behavior and had done the same
type of workaround.

So, I realize this isn't much help right now, but we lost 4 days
figuring this out so now the project is behind schedule.

 From a high level (which probably won't help much), we have very fine
grained timings in our application. So, we have timings around just the
single call to renderx to trigger the transformation via SAX. As soon
as that completes, it stops. That piece is the only piece of our app
that as we add threads and processors gets slower. As another
datapoint, when we remove renderx and just render to a file, it scales
fine. (Doing all the same code, just not calling renderx) Also, with
FOP in there, it scales fine. I don't know what other conclusions to
draw. Our load balancer also makes it scale fine.

Like I said, hopefully I can write a test program that exercises it the
way we do and can hand that over.

For now, the load balancer is working great.

Irv

David Tolpin wrote:

>
> On 22.04.2005, at 23:23, Irv Salisbury III wrote:
>
>> I am not using En Masse. I am using straight up XEP. It definitely
>> is in the XEP code. (As can be expected from your previous emails)
>> I wrote a load balancer specific to our app and it now scales
>> linearly. (With XEP in only one thread per VM)
>>
>> Try testing with straight up XEP and you will see the contention. On
>> solaris, you can actually use a status tool to see the contention.
>>
>
> Irv,
>
> CLISER/EnMasse IS a straight up XEP with several threads running
> inside a single virtual machine. I have tested on a multi-processor
> configuration with multiple threads, and I don't see contention. Could
> you please find out and check what exact stage of formatting causes
> contention in your case?
>
> My previous e-mails had explained what was synchronized in the
> formatting kernel, but these synchronization do not cause noticeable
> slow-down - they are infrequent and critical sections are short.
>
> David
>
> -------------------
> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
> in the body of the message to majordomo@renderx.com from the address
> you are subscribed from.
> (*) By using the Service, you expressly agree to these Terms of
> Service http://www.renderx.com/tos.html

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
Received on Fri Apr 22 15:11:27 2005

This archive was generated by hypermail 2.1.8 : Fri Apr 22 2005 - 15:11:27 PDT