Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > JMS vs Sockets -- bandwidth, size, speed, etc.

Reply
Thread Tools

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

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-27-2012
On 12/27/2012 2:35 AM, Kevin McMurtrie wrote:
> In article <(E-Mail Removed)>,
> me2 <(E-Mail Removed)> wrote:
>> 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.

>
> 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




 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-27-2012
On 12/27/2012 6:13 AM, Arved Sandstrom wrote:
> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
>> 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.


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


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-27-2012
On 12/26/2012 11:46 PM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> 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


 
Reply With Quote
 
Sven K÷hler
Guest
Posts: n/a
 
      12-27-2012
Am 27.12.2012 19:18, schrieb Arne Vajh°j:
> On 12/27/2012 8:26 AM, Sven K÷hler wrote:
>
>> 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.


I see your point.
Maybe, I just met too many people overlooking that option.
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-27-2012
On 12/27/2012 1:47 PM, Sven K÷hler wrote:
> Am 27.12.2012 19:18, schrieb Arne Vajh°j:
>> On 12/27/2012 8:26 AM, Sven K÷hler wrote:
>>> 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.

>
> 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


 
Reply With Quote
 
Kevin McMurtrie
Guest
Posts: n/a
 
      12-28-2012
In article <c3WCs.31155$(E-Mail Removed)>,
Arved Sandstrom <(E-Mail Removed)> wrote:

> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
> > In article <(E-Mail Removed)>,
> > me2 <(E-Mail Removed)> wrote:
> >
> >> 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.
> >

> 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.
--
I will not see posts from Google because I must filter them as spam
 
Reply With Quote
 
me2
Guest
Posts: n/a
 
      12-28-2012
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
On 12/28/2012 10:25 AM, me2 wrote:
> 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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-28-2012
On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
> In article <c3WCs.31155$(E-Mail Removed)>,
> Arved Sandstrom <(E-Mail Removed)> wrote:
>> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
>>> 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.

>
> 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


 
Reply With Quote
 
me2
Guest
Posts: n/a
 
      12-28-2012
On Friday, December 28, 2012 10:50:54 AM UTC-5, Arne Vajh°j wrote:
> On 12/28/2012 10:25 AM, me2 wrote:
>
> > 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


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
implementing or using jms or running jms without application server ravinder.ggl@gmail.com Java 0 06-26-2007 10:26 AM
How to setup JBoss for JMS (not MDB-JMS) ? Thomas Stein Java 0 10-18-2004 09:10 PM
JMS and servlets iksrazal Java 0 07-30-2003 09:27 PM
JMS Question Dane Java 1 07-30-2003 03:38 PM
video capture using JMS Zamf Java 0 07-05-2003 08:33 PM



Advertisments