Re: JMS vs Sockets -- bandwidth, size, speed, etc.
me2 wrote:
I think that I didn't phrase my question well enough.
You are mistaken. You phrased it just fine.
There are two metrics that I am curious about--bandwidth usage and speed.
We understood that. We are not stupid.
The advice given stands.
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?
Okay ...
I can test the speed and so far, the sockets seem to win as long as there
Good.
are not a lot of consumers (otherwise the threading seems to choke it).
This is consistent with the advice you've been given - measure under conditions
approximating your projected deployment, compare costs and benefits, and to
consider that faster than fast enough might not be worth it.
It is not usually simple to create meaningful benchmarks, and without knowing
the protocols, as pointed out upthread, it is impossible to make meaningful
statements about the results.
You state that you've run tests. Good on ye. Other people's experience is in
general not at all comparable to yours. The answers upthread gave as much as
possible given your parameters here.
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
That depends entirely on the protocol used to encode the message in either
case.
smaller--you don't have wrappers or envelopes or meta data but instead just
The use of sockets vs. JMS is not germane to message size. Sockets have nothing
to say about message size whatsoever. Zip. Nada. The train will grow as many
cars as it needs to carry however much cargo you lade.
JMS is an API. There is some overhead in coordinating message senders and
recipients. That overhead exists also in roll-your-own schemes.
the data. So how much larger is the JMS message?
Sigh.
--
Lew