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

[me2]

Greetings,

I am a newbie to JMS and would appreciate some advice.

Has anyone compared JMS to socket programming? If I have N number of clients that need to connect to and send messages to 1 server, what is the comparison? I would guess that sockets--direct from a client to the server--would be the fastest for speed and maybe take the least bandwidth. But I would expect that there would only be negligible size increases for the JMS overhead once the connection was established and I would expect that a pub-subtopic would be able to smoke through sending the N number of clients messages, rather than loop through the connections/sockets and sending the message to each of them.

Has anyone else looked at this? I'm going through the exercise to set up aJMS server, but I thought maybe someone else could point me in the right direction.

Cheers,
me2

 

[Lew]

Has anyone compared JMS to socket programming? If I have N number of clients
that need to connect to and send messages to 1 server, what is the
comparison? I would guess that sockets--direct from a client to the server--
would be the fastest for speed and maybe take the least bandwidth. But I
would expect that

Beware expectations.

there would only be negligible size increases for the JMS overhead once the
connection was established and I would expect that a pub-sub topic would be
able to smoke through sending the N number of clients messages, rather than
loop through the connections/sockets and sending the message to each of them.

Apples vs. oranges.

JMS uses what under the hood?

Well, sometimes sockets but that depends. For certain processes you might
see in-memory transfers.

Or shared memory.

And how much speed do you need, and do you need it in development to get
correct operation, or at runtime to get wrong operation quicker?

How much time and money and aggravation are you willing to spend re-inventing
messaging?

Has anyone else looked at this? I'm going through the exercise to set up a
JMS server, but I thought maybe someone else could point me in the right
direction.

The only way to compare speed is to measure actual implementations.

And you might be measuring the wrong thing.

Plus, socket implementations can be very naive. NIO or threads?

Under what loads? How much competition for resources? With what latencies?

How much speed do you need? How much safety?

Who pays for support when there are problems?

How will it scale? How much does it even need to scale?

You've been asking the wrong questions for this stage, I'm advising.

 

[Arne Vajhøj]

I am a newbie to JMS and would appreciate some advice.

Has anyone compared JMS to socket programming? If I have N number of
clients that need to connect to and send messages to 1 server, what
is the comparison? I would guess that sockets--direct from a client
to the server--would be the fastest for speed and maybe take the
least bandwidth. But I would expect that there would only be
negligible size increases for the JMS overhead once the connection
was established and I would expect that a pub-sub topic would be able
to smoke through sending the N number of clients messages, rather
than loop through the connections/sockets and sending the message to
each of them.

Has anyone else looked at this? I'm going through the exercise to
set up a JMS server, but I thought maybe someone else could point me
in the right direction.

If you are moving data between two systems connected via
a TCP/IP network, then you will be using sockets.

So the question is whether to use socket API or JMS API.
A third option would be RMI.

It is obvious that adding layers on top of sockets can
not produce something faster than optimal usage of
sockets. There will be somewhere between utterly insignificant
and completely devastating overhead by adding an extra layer.

If you want to know for sure then measure in your specific
context.

But I am surprised that you only seem to focus on
the performance aspect.

The differences in functionality provided seem
much more important to me.

async only or also sync request-response?
Java SE daemon or Java EE app as server?
support for non-Java clients or servers?
need for transactions?
need for redundancy?

Arne

 

[mcheung63]

I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.

 

[Lew]

I believe socket has the best performance, i [sic] tried to user [huh?]
socket and pipeline to send data to a c++ [sic] program, socket win [sic].

Sorry, "pipeline"?

How does that compare to, say, a JMS in-memory transfer?

Under what conditions did you do the measurements?

What was your definition of "win"?

Did your C++ program do anything significant with the data? Under
what load? What competing loads? How many clients? Any threading issues?

Your post provides so little detail as to be effectively useless.

 

[Kevin McMurtrie]

Greetings,

I am a newbie to JMS and would appreciate some advice.

Has anyone compared JMS to socket programming? If I have N number of clients
that need to connect to and send messages to 1 server, what is the
comparison? I would guess that sockets--direct from a client to the
server--would be the fastest for speed and maybe take the least bandwidth.
But I would expect that there would only be negligible size increases for the
JMS overhead once the connection was established and I would expect that a
pub-sub topic would be able to smoke through sending the N number of clients
messages, rather than loop through the connections/sockets and sending the
message to each of them.

Has anyone else looked at this? I'm going through the exercise to set up a
JMS server, but I thought maybe someone else could point me in the right
direction.

Cheers,
me2

JMS is about topic management, queue management, message persistence,
and reliable distribution in a complex environment prone to failures.
If you don't need any of that, like a log host, you'll be much happier
with a plain socket. If you do need that stuff you probably want a JMS
implementation rather than writing it yourself.

JMS services are typically very heavy weight. Memory and disk space are
needed to buffer data to nodes that temporarily fall behind or go
offline. Configuration can take a while too.

 

[Arved Sandstrom]

JMS is about topic management, queue management, message persistence,
and reliable distribution in a complex environment prone to failures.
If you don't need any of that, like a log host, you'll be much happier
with a plain socket. If you do need that stuff you probably want a JMS
implementation rather than writing it yourself.

JMS services are typically very heavy weight. Memory and disk space are
needed to buffer data to nodes that temporarily fall behind or go
offline. Configuration can take a while too.

It's funny how people can come at things from a different perspective.
In my world messaging providers like JMS providers or WMQ (and JMS and
MQ clients) are _lightweight_. I actually stopped and tried to process
your "novel" concept for a few seconds.

AHS

 

[Sven Köhler]

Am 27.12.2012 01:00, schrieb Arne Vajhøj:

So the question is whether to use socket API or JMS API.
A third option would be RMI.

If performance is a concern, better not use RMI. One call to a method
(e.g. in order to deliver some data to the peer) will always take at
least one roundtrip, as the caller side has to wait until the method
(even if it is void) returns.

A fourth option is to use object serialization without RMI, i.e.
ObjectOutputStream and ObjectInputStream. It is worth it, if your
protocol allows you to send multiple objects (or messages for that
matter) without having to wait for a reply.


Regards,
Sven

 

[Robert Klemme]

I believe socket has the best performance, i tried to user socket and
pipeline to send data to a c++ program, socket win.

That statement is pretty meaningless. First, we do not know what you
did, i.e. what you measured. Then, you did not make any statement
whatsoever how big the difference is. Third, engineers usually deal
with tradeoffs: it could well be that 5% performance penalty is well
worth the 5 weeks savings in development time to implement your own
protocol using a socket. (Eventually you may find out that by that time
the 5% performance reduction is actually a 10% performance advantage
because your home grown version is slower because of some quirk in your
own implementation.)

Kind regards

robert

 

[Arne Vajhøj]

Am 27.12.2012 01:00, schrieb Arne Vajhøj:

If performance is a concern, better not use RMI. One call to a method
(e.g. in order to deliver some data to the peer) will always take at
least one roundtrip, as the caller side has to wait until the method
(even if it is void) returns.

If the requirements are for true async, then RMI is not a good fit
as it is always sync request-response.

A fourth option is to use object serialization without RMI, i.e.
ObjectOutputStream and ObjectInputStream. It is worth it, if your
protocol allows you to send multiple objects (or messages for that
matter) without having to wait for a reply.

I am not sure that I would count that as a distinct option.

The socket option will need something on top of it.

PrintWriter/BufferedReader
ObjectInputStream/ObjectOutputStream
DataInputStream/DataOutputStream
etc.

Arne

 

[Arne Vajhøj]

JMS is about topic management, queue management, message persistence,
and reliable distribution in a complex environment prone to failures.
If you don't need any of that, like a log host, you'll be much happier
with a plain socket. If you do need that stuff you probably want a JMS
implementation rather than writing it yourself.

JMS services are typically very heavy weight. Memory and disk space are
needed to buffer data to nodes that temporarily fall behind or go
offline. Configuration can take a while too.

JMS is just an API. Different message queue software comes
with different overhead.

Clustering, persistence, transactions etc. are optional
features that one does not enable if they are not needed.

Arne

 

[Arne Vajhøj]

It's funny how people can come at things from a different perspective.
In my world messaging providers like JMS providers or WMQ (and JMS and
MQ clients) are _lightweight_. I actually stopped and tried to process
your "novel" concept for a few seconds.

JMS can be what you make it be.

A non-persisted non-transactional queue with sender and
receiver in same JVM and a clustered persisted transactional
with XA queue with queue, sender and receiver in 3 different
JVM's are pretty different in relation to overhead and
infrastructure requirements.

Arne

 

[Arne Vajhøj]

I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.

Hmmm.

How did you test JMS from C++?



Arne

 

[Sven Köhler]

Am 27.12.2012 19:18, schrieb Arne Vajhøj:

I am not sure that I would count that as a distinct option.

The socket option will need something on top of it.

I see your point.
Maybe, I just met too many people overlooking that option.

 

[Arne Vajhøj]

Am 27.12.2012 19:18, schrieb Arne Vajhøj:

I see your point.
Maybe, I just met too many people overlooking that option.

It can certainly be convenient.

I have used it a lot myself.

Arne

 

[Kevin McMurtrie]

It's funny how people can come at things from a different perspective.
In my world messaging providers like JMS providers or WMQ (and JMS and
MQ clients) are _lightweight_. I actually stopped and tried to process
your "novel" concept for a few seconds.

AHS

They're almost lightweight without the high reliability options, but
those are the same options that cause people to choose JMS rather than
an in-house solution. FFMQ is a lightweight codebase but it's still
going to hit disk I/O fairly hard. ActiveMQ is a resource-consuming
beast when faced with reliable delivery to clients that are lagging.
ActiveMQ also has dependencies on half the Internet so it's prone to
creating library conflicts.

 

[me2]

Good morning,

I think that I didn't phrase my question well enough. There are two metrics that I am curious about--bandwidth usage and speed. For X messages of N length (assume a constant size) going to each of Y consumers (so, X * Y messages total), what is the comparison? I can test the speed and so far, thesockets seem to win as long as there are not a lot of consumers (otherwisethe threading seems to choke it). That leaves the bandwidth question--howmuch larger (if any) is a JMS message on the wire vs in a socket. I wouldhazard (as a newbie) that the socket is smaller--you don't have wrappers or envelopes or meta data but instead just the data. So how much larger is the JMS message?

Thank you,
me 2

 

[Arne Vajhøj]

I think that I didn't phrase my question well enough. There are two
metrics that I am curious about--bandwidth usage and speed. For X
messages of N length (assume a constant size) going to each of Y
consumers (so, X * Y messages total), what is the comparison? I can
test the speed and so far, the sockets seem to win as long as there
are not a lot of consumers (otherwise the threading seems to choke
it). That leaves the bandwidth question--how much larger (if any) is
a JMS message on the wire vs in a socket. I would hazard (as a
newbie) that the socket is smaller--you don't have wrappers or
envelopes or meta data but instead just the data. So how much larger
is the JMS message?

Why do you think speed and bandwidth are the most important
criteria for deciding between sockets and JMS? I have never
seen that choice made for only performance reasons.

JMS is just an API, so JMS does not have a specific size overhead.
Each implementation will have different size overhead.

And if the socket code is slower than the JMS code for large number
of consumers then that only means that the socket code is not
optimal written.

Arne

 

[Arne Vajhøj]

They're almost lightweight without the high reliability options, but
those are the same options that cause people to choose JMS rather than
an in-house solution.

That may be how you use message queue solutions.

But there are other that use message queues without the
reliability options.

ActiveMQ is a resource-consuming
beast when faced with reliable delivery to clients that are lagging.
ActiveMQ also has dependencies on half the Internet so it's prone to
creating library conflicts.

????

How?

The ActiveMQ jars and the applications jars should not be
mixed at all. Either different JVM or different apps within the
same app server. Only exception I can think of is embedded
inside an SE app, which is not a common scenario.

Arne

 

[me2]

Why do you think speed and bandwidth are the most important

criteria for deciding between sockets and JMS? I have never

seen that choice made for only performance reasons.



JMS is just an API, so JMS does not have a specific size overhead.

Each implementation will have different size overhead.



And if the socket code is slower than the JMS code for large number

of consumers then that only means that the socket code is not

optimal written.



Arne

Good morning Arne,

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'mnot sure how this would scale for 10 consumers, 100 consumers, etc.

The bandwidth size is the most important priority because of a number of considerations--I can't justify using JMS if it uses 10 times the bandwidth--so I have to figure out how to measure that. 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.

So that's how it goes. I'm looking at Wireshark but I'm very new to it, soI am going to have to figure out how that works.

Thanks for your point of view,
me2