[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Performances

Hi Yves,

Yves Claereboudt wrote: 
First of all, congratulations for bringing such a nice development to the open source community.

Thanks ;)

In order to evaluate the performance of xmlblaster in replacement of an off-the-shelf product, I modified the HelloWorld.c demo into a simple C client generating publishOneway as fast as it can . The client only takes 1.2% of the CPU time on an old HP-UX machine (PA8500 2.0 300 Mhz).

Here is an extract of the client:
   for (i=0; i< 10000; i++)
   {
        xb->publishOneway(xb, &msgUnitArr, &exception);
         if (*exception.errorCode != '\0')
         {
                printf("[HelloWorld] Caught exception in publish errorCode=%s, message=%s\n",
                       exception.errorCode, exception.message);
                freeXmlBlasterConnectionUnparsed(xb);
                exit(1);
         }
    }


You need to run more messages since the throughput starts to stabilize around the first 10000 messages. Try to run 50000 and measure the last 10000.

The server rel 1.0.2 runs on a Pentium 4 at 1.2 GHz with JRE 1.4.2_03.
There is no subscription pending.

By using sockets, I was expecting better results than with CORBA (http://www.xmlblaster.org/performance.html) and obtained a throughput of 400 messages / seconds.
The limit is not the network as the server takes 99% of the CPU time.

the mentionned page is unfortunately really outdated (even before we implemented the queues and other features) and the current performance is not so good as it used to be.

I did some tests for a couple of days ago however. It was on an AMD64 3000 (1.7 GB 64 bits) with two different jdks (the second is the new optimized for AMD64), here the results:

jdk1.5.1: 1250 msg/sec
jdk1.5.1AMD64: 1315 msg/sec

When using the standard publish method, the throughput is 310 messages/s.

a) Am I doing something wrong ?

Even if the performance is not what it used to be I would expect more from your tests:

- did you shoot off logging ?
- did you use transient messages ?

b) Should we expect improvement of throughput in future releases ?
Of course. In the last year we focused around stability more than around performance. Now we have a stable release and if there is the need for better performance I think we will analyse that.

c) Any plan for writing a high performance version of the server in C++ ?
There currently are not such plans. There is already a lot of c++ "material" from the client library which could be used for a "reduced and fast" c++ server (for instance queuing is already there) and I don't think it would be a huge amount of work, however we all know what "little" means in the developer's community ;)

So if you would be interested in pushing forward such a subproject you are welcome ...


Thanks,

Yves Claereboudt

DISCLAIMER :

The contents of this e-mail message and any attachments are intended solely for the addressee(s) named in this message. This communication is intended to be and to remain confidential and may be subject to applicable work product privileges. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Ion Beam Applications therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.