users@fi.java.net

Re: Non-FI performance problems

From: Mark Swanson <mark_at_ScheduleWorld.com>
Date: Thu, 19 Jan 2006 13:28:35 -0500

Paul Sandoz wrote:
> Hi Mark,
>
> Can you send the code that does the measurement and i might be able to
> spot if the stax implementation is being used optimally or not?

The code I'm using to do the measurement is on the client, and stax is
used in the server implementation. So I'm sure this won't help you much
be since you asked here you go:
(binding is the appropriate Axis client stub. _year and _firstName are
generated by Axis and correlate to XmlBeans on the server)

     // Test
     for (int j=0; j < 20; ++j) {
       long start = System.currentTimeMillis();
       for (int i=0; i < loopCount; ++i) {
         x.client.test._firstName firstName =
           binding.test(new x.client.test._year());
       }
       long end = System.currentTimeMillis();
       System.out.println("loops:" + loopCount + ", in ms:" + (end-start));
     }


>
> Mark Swanson wrote:
>> Before I tested the nice time/space FI compression I wanted to make
>> sure that normal non-FI clients would still perform well. In summary I
>> found that the FI stax implementation for non-FI clients was about
>> 1.85x slower than woodstox and about 1.4x slower than the RI.
>>
>
> What is a "non-FI client"? I am slightly confused what it means for a
> "FI stax implementation for a non-FI client".

Sorry. I tried to come up with an abbreviation that saved me from typing
Fast Infoset. For example, my Axis-based test client does not use
FastInfoset so I called it a non-FI client. I will stop doing that.

>
>> I tested the 3 implementations using XFire and XmlBeans using a
>> document/wrapped service with a small XmlBean argument.
>>
>> I loop through the remote method 50 times and print how long that took
>> 20 times. I did the test 3 times for each stax implementation to allow
>> hotspot some time to do its stuff (at least on the server side).
>>
>> The tiny SOAP envelope is:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Body>
>> <test xmlns="http://DefaultNamespace">
>> <ns1:year
>> xmlns:ns1="http://webservices.optimalpayments.com/xact">0</ns1:year>
>> </test>
>> </soapenv:Body>
>> </soapenv:Envelope>
>>
>> The response was even smaller as the XmlBean return object/document
>> was empty.
>>
>
> Note that for very small messages you will not see a large performance
> difference between processing XML documents and Fast Infoset documents
> because there is not a lot of repeating information in the document
> (e.g. try GZIPing it and you will probably get about 50% compression).

Thanks - I do understand. At the moment I'm trying to test the straight
stax processing speed. I will test the Fast Infoset capabilities shortly.

Cheers.

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb