|
|
|
|||||
|
Since we are on this topic, let us once again return to just the octet performance. (I think Marc has prev. said that for large msg sizes Ice prob. has some optimizations that can be done; this seems esp. true when structs are involved.)
Attached graphic shows TAO and ORBexpress (1.3.1 and 2.3.5 versions, respectively), with default concurrency and with "single threaded" configuration. Here one sees that TAO 1.3.1 "default" configurations is slower than Ice 1.0.1. However, there is a cross over for larger msg sizes. You will be able to gain this back with some optimizations. The purpose of my work is not to understand performance issues in the large and in the small. Thus, I hope the numbers speak for themselves - we have no commercial interests in any of the stuff we study. Gautam |
|
||||||
|
Quote:
Quote:
As for OrbExpressRT, I must admit that we can't reach their performance. |
|
|||||
|
Actually, I made a typo. Our purpose *IS* to understand performance issues in the large and small scales. Thus I try to collect data such as shared memory, TCP/IP, various ORBs and other MW, RMI, EJB etc. And when doing a lot of testing of course configurations are important. (Hopefully we are not making any gross errors but constant cross checking helps - for example, IIOP based ORBs better always be slower than TCP, etc.)
I will try to see about the "nested" test that you mentioned. Gautam |
|
|||||
|
Hi Gautam,
I was thinking last night -- one of the things that Ice has which is "new and different" from other middleware is the ability to compress messages. For use cases such as yours (varying packet sizes) I'd guess this could make a significant difference, if the payload is compressible. What are you using for your messages? Any chance you could run that same benchmark with protocol compression on and see how it performs? I'm quite curious about this -- I'd be interested to know if the bzip2 compression and trading cpu cycles for network latency has a reasonable effect. Of course if you're sending chunked .jpeg files or something it won't help at all ;-) |
|
||||||
|
Over a fast network (or even loopback), compression will rather slow down requests. Compression is intended to be used for slow connections, like modems.
Anyway, we already know what the problem with long messages is. We will fix this in the next release. |
|
|||||
|
Marc,
That's interesting to know. The documentation doesn't mention anything about that fact (that compression is for an intended use case) -- perhaps it would be useful to note there? Do you expect there's any payload size where it would make a difference over TCP (say, 5 MB)? With your post in the announcements forum about Mutable Realms and their "Wish" game I have a guess as to which customer requested this feature. |
|
||||||
|
Quote:
You can make a simple test: Take a 5MB file, and compress it with bzip2 -1, and measure the time. Compare this time to the time needed to send the 5MB file over your network. I'm pretty sure the compression time will be longer in this case. Quote:
For Mutable Realms' game project, lowering the bandwith consumption is very important. They don't use compression within the backend, but it is used for all communications between backend and the game client. Using Glacier, this can all be done transparently. |
|
|||||
|
Comparing Ice 1.0.1 with Ice 1.1.0
For sake of completeness I repeated my prev. roundtrip latency measurements with Ice version 1.1.0. In attached graphs I show roundtrip latencies for "octet" and "struct" messages of different sizes. (Details are in prev. postings of these thead.)
While the compiler was kept constant at GCC 3.2.1 the hardware underwent an OS change from Linux 2.4.18 to 2.4.20. So I also show on each chart corresponding TCP/IP roundtrip latencies. While Ice 1.1.0-octet measurement is slower than Ice 1.0.1 measurement the difference is essentially the same by which the kernel has slowed down. One sees similar diff for 1.1.0-struct at small message sizes, but it seems that 1.1.0 has been improved over 1.0.1 for array of structs being transported. Note: I just realized that I think I can only attach 1 file per posting. So I will "octet" graphic here and will attach "struct" data with next post and "both" on the 3rd graphic. Sorry if I missed a way to attach multiple .png files in one posting. As usual, all data is at: http://www.atl.external.lmco.com/projects/QoS -> "MW_Comparator" and Ice and TCP subset of results can be reached more easily at: http://www.atl.external.lmco.com/pro....*transport%29 Gautam Thaker |
|
|||||
|
Part III of Ice 1.0.1 and 1.1.0 comparison
Here is the final graph which shows all data together.
Gautam |
|
|||||
|
omniORB performance
Hi,
in my current project i employed TAO, after some simple tests it turned out that TAO is by several times slower than omniORB. (i've moved to omniORB right now) Please consider the following results provided by http://nenya.ms.mff.cuni.cz/projects...ts-xampler/All (Distributed Systems Research Group, Charles University, Prague) Real time does not mean high performance. In my opinion it doesn't make much sense to compare TAO with ICE. An extensive comparison between omniORB and ICE would be extremely interesting. (Since I'm with embedded stuff the memory footprints are of a major interest too) Anyway, congratulations to the ICE developers, it seems to be great^^ |
|
||||||
|
We might include omniORB in future performance comparisons, but don't hold your breath. It's a lot of work to do these tests thoroughly.
As for realtime, I yet have to understand what this really means in the context of non-realtime operating systems and non-realtime transports... Last edited by marc : 04-12-2005 at 07:59 AM. |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| about performance | fengxb | Help Center | 7 | 01-12-2007 06:55 AM |
| what performance ice vs ace? | BSanLang | Comments | 1 | 10-13-2006 03:20 PM |
| Ice Performance | marc | Announcements | 0 | 03-28-2005 08:29 PM |
| Ice vs. JNI throughput performance? | brian | Help Center | 4 | 06-11-2004 02:17 AM |
| Ice performance ? | ChMeessen | Comments | 5 | 09-25-2003 12:47 PM |