1) I'm not familiar with the MFC IOPC api, but i would not be surprised
to see native Windows (or any other platform) application to outperform
java app. My understanding is that Java Windows NIO implementation uses
'select' api (that is stadandrd Berkley sockets compatibility layer)
that does not have the performance level as native overlapped IO api.
When comparing JProactor performance on the same hardware RedHat Linux
did shown about 20% higher throughput than on Windows.
The other test that we performed was to compare performance of a simple
echo server app implemented by JProactor and TProactor using
TProactor based client (on the same hardware) - The difference in our
case again roughly about 20%.
2) Our application is not mission critical, we have about 50 concurrent
connections. Again that application did have great performance
requirements. The original idea was to implement truly asynchronous API
that will allow better implementations of network protocols.
At the same similar patters used in the TProactor implementation were
used to develop JProactor.
At this stage we are committed to improve and continue work
on JProactor. So if there are any ideas/suggestions on how to improve
performance of JProacotr we would gladly consider/discuss them.
Again thank you for your interest.
Kind regards
Yevgeny
----- Original Message -----
From: "Haiyun Wang" <haiyun_wang@hotmail.com>
To: <ylibman@terabit.com.au>
Sent: Tuesday, August 08, 2006 7:05 AM
Subject: Re: trial of your jproactor
> Dear support,
>
> 1) I did see some throughtput test in your article comparing with C++, C#
> implementation. I also did some tests of your JProactor, which turned out
> the throughtput was so "bad" comparing to
> MFC's IOPC.(Correct me if i am wrong). However it is stable, I created 500
> connections by using MFC IOPC socket client. No connection is lost in 2
> days. As you mentioned in your email, Java is "slower" due to its native
> call?
>
> 2) Is it possible to tell me how good the JProactor(or bad ^^) acts in your
> commerical project? Actually I am working on missision critical
> project(finincial related). The performance is really important to us.
>
> 3) Should we move our discuss here to the forum? Did you check it very often
> since I didn't see any discussions in it.
>
> Thanks. Have a nice day.
>
> Henry
>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why is there so much difference between the Java 1.5 and Java 1.4 versions of the Demultiplexor? Aren't they the same except for using Lea's concurrent versus the 1.5 concurrent packages?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While migrating JProactor from Java 1.4. to 1.5 not only concurrent package has been changed but also usage of atomic classes were introduced. Another major change was introduction of asynchronous SSL channels. We also've done some refactoring/optimisations - look ahead of IO operations to minimize context switching.
Hope this helps.
Regards,
Yevgeny
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Henry,
Please find my answers below:
1) I'm not familiar with the MFC IOPC api, but i would not be surprised
to see native Windows (or any other platform) application to outperform
java app. My understanding is that Java Windows NIO implementation uses
'select' api (that is stadandrd Berkley sockets compatibility layer)
that does not have the performance level as native overlapped IO api.
When comparing JProactor performance on the same hardware RedHat Linux
did shown about 20% higher throughput than on Windows.
The other test that we performed was to compare performance of a simple
echo server app implemented by JProactor and TProactor using
TProactor based client (on the same hardware) - The difference in our
case again roughly about 20%.
2) Our application is not mission critical, we have about 50 concurrent
connections. Again that application did have great performance
requirements. The original idea was to implement truly asynchronous API
that will allow better implementations of network protocols.
At the same similar patters used in the TProactor implementation were
used to develop JProactor.
At this stage we are committed to improve and continue work
on JProactor. So if there are any ideas/suggestions on how to improve
performance of JProacotr we would gladly consider/discuss them.
Again thank you for your interest.
Kind regards
Yevgeny
----- Original Message -----
From: "Haiyun Wang" <haiyun_wang@hotmail.com>
To: <ylibman@terabit.com.au>
Sent: Tuesday, August 08, 2006 7:05 AM
Subject: Re: trial of your jproactor
> Dear support,
>
> 1) I did see some throughtput test in your article comparing with C++, C#
> implementation. I also did some tests of your JProactor, which turned out
> the throughtput was so "bad" comparing to
> MFC's IOPC.(Correct me if i am wrong). However it is stable, I created 500
> connections by using MFC IOPC socket client. No connection is lost in 2
> days. As you mentioned in your email, Java is "slower" due to its native
> call?
>
> 2) Is it possible to tell me how good the JProactor(or bad ^^) acts in your
> commerical project? Actually I am working on missision critical
> project(finincial related). The performance is really important to us.
>
> 3) Should we move our discuss here to the forum? Did you check it very often
> since I didn't see any discussions in it.
>
> Thanks. Have a nice day.
>
> Henry
>
Why is there so much difference between the Java 1.5 and Java 1.4 versions of the Demultiplexor? Aren't they the same except for using Lea's concurrent versus the 1.5 concurrent packages?
Hi Mike,
While migrating JProactor from Java 1.4. to 1.5 not only concurrent package has been changed but also usage of atomic classes were introduced. Another major change was introduction of asynchronous SSL channels. We also've done some refactoring/optimisations - look ahead of IO operations to minimize context switching.
Hope this helps.
Regards,
Yevgeny