Re: JMS vs Sockets -- bandwidth, size, speed, etc.

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 29 Dec 2012 20:52:04 -0500

Message-ID:

<50df9e4d$0$284$14726298@news.sunsite.dk>

On 12/28/2012 11:44 AM, me2 wrote:

The socket code clocked faster when processing 1 consumer and 1
producer than my quick throw-together of JMS with 5 consumers and 1
producer. Both sent 10 character strings 10,000 times. I'm just
getting back into Java, so I'm sure that the socket programming was
not as optimized as it could be--but there was 3 consumers and 1
producer and it still was faster than the 1 producer/5 consumer JMS
setup. The multiple consumers connected to a socket/thread setup as
illustrated by Oracle in their KnockKnock example--so I'm not sure
how this would scale for 10 consumers, 100 consumers, etc.

Given that your message queue also uses sockets, then you know that
sockets can do better with more clients.

The bandwidth size is the most important priority because of a number
of considerations--

Message queues are usually used within data centers with
Gbit networks.

I can't justify using JMS if it uses 10 times the
bandwidth--so I have to figure out how to measure that.

Unless you are charged per byte, then I don't think there is any
point.

Actual throughput is what is relevant.

The next
thing is speed--how fast can the X number of messages go through.
The next priority is maintainability and somewhere else down the list
is scalability.

Have you proven that the most simple and most maintainable solutions
actually have a performance problem?

Arne