Which is faster: EJB3-CORBA-SOCKETS-etc.

[Darrin Smith]

Anyone know of a good test that shows the performance differences between CORBA, EJB3, SOAP(slow, but how much slower), SOCKETS, etc.?

I Googled but didn't see much (a lot of EJB -vs- .Net though).

Thanks!

[William Brogden]

I don't know of any performance comparison - anyway it would be hard to come up with representative test cases.

Obviously, the closer you get to raw sockets the faster you go but the more work your custom code has to do.

Is this just academic interest or do you have a specific application in mind?

Bill

[Darrin Smith]

Originally posted by William Brogden:
Is this just academic interest or do you have a specific application in mind?

Bill

Quite specific! So much so that I may need to roll my own comparison test. We are talking millions of hits a day with varying amounts of data going across the wire (all under 20K though I would think) with thousands of concurrent users.

[William Brogden]

COOL! An interesting problem at last.

Next question - what are these thousands of users going to have for client software? Do you get to specify it? Provide it? What do they do with the response when they get it?

How much do we know about the client side in other words.

Another question - how unique is each client interaction? The point being that formatting a unique SOAP (for example) response is pretty time consuming - compared to pulling a stock message out of a cache.

Bill

[Darrin Smith]

COOL! An interesting problem at last.

Yes it is!

Next question - what are these thousands of users going to have for client software? Do you get to specify it? Provide it? What do they do with the response when they get it?

Well, here is the way it is. We will only have a few clients (let's say four), but those clients have thousands of clients of their own that concurrently need information from our clients who in turn get that information from us. So, our clients get millions of hits per day from thousands of users and they in turn hit us a multiple of that (one client hit often results in many hits to us to get the data they need).

We can specify the interface to the few we work with directly (currently use CORBA to communicate), and the way they talk to their clients we don't really care much about (HTTP mostly but other means as well).

How much do we know about the client side in other words.

All we need to.

Another question - how unique is each client interaction? The point being that formatting a unique SOAP (for example) response is pretty time consuming - compared to pulling a stock message out of a cache.

The interface to each of the clients is the same, and for purposes of the test can be assumed to be the same.

In fact, for the test, I'd be happy with just a few methods...one to request 1K of data, one for 5K and one for 10K (static..not read from a database, but saved off in memory since I'm not worrying about database performance here...we don't need to). The data itself, although not changing in the test, will be different for each call in the real world.
[ December 01, 2006: Message edited by: Darrin Smith ]

[William Brogden]

We can specify the interface to the few we work with directly

Aha! so you really only talk directly to a few clients who can adapt to whatever tools you choose. Sounds like you should be able to stay close to the bare sockets as possible.

Assuming no network firewall problems you could even go with straight sockets sending byte streams - after all that layer is in every other technique so it is the fastest possible. I have actually done something like this where I sent byte[]s and the client used Perl to interpret the data as Strings.

You could even keep the sockets open, one for each of the direct clients and have clients queue up requests - opening a socket for each request is a bit time consuming.

However it may be more convenient to go with URLConnection type addressing to let the Java library handle the messy details. Depending on what your direct clients do with the data, they might love to get the data as some general XML format that could be reformatted with XSLT and similar tools.

What fun
Bill

[Jeroen T Wenting]

You will also need to define where you want your performance.
Optimising network throughput may mean more work on the server for example.
And going with a GOOD EJB implementation could well mean higher performance than a less well created custom solution (depending on the skill and budget you have available on your end of course).
It's almost certainly to be faster to build at the very least.

[Darrin Smith]

Just a quick update...

So far we've tested CORBA against EJB 3. Next up is Web Services (I know...slower...but we want to know by how much) then probably RMI.

For the vendor used for both the ORB and the app server, EJB 3 shows much better performance across the board (data packets sized 2K to 50K) with the larger data packets REALLY favoring EJB 3. We will probably wnat to try other ORB/App server vendors to see how this affects things though.