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

Discussion in 'Java' started by me2, Dec 26, 2012.

  1. me2

    me2 Guest

    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
     
    me2, Dec 26, 2012
    #1
    1. Advertising

  2. me2

    Lew Guest

    me2 wrote:
    > 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.

    --
    Lew
     
    Lew, Dec 26, 2012
    #2
    1. Advertising

  3. me2

    Arne Vajhøj Guest

    On 12/26/2012 4:26 PM, me2 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.


    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
     
    Arne Vajhøj, Dec 27, 2012
    #3
  4. me2

    Guest

    I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.
     
    , Dec 27, 2012
    #4
  5. me2

    Lew Guest

    On Wednesday, December 26, 2012 8:46:02 PM UTC-8, wrote:
    > 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.

    --
    Lew
     
    Lew, Dec 27, 2012
    #5
  6. In article <>,
    me2 <> 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.
    --
    I will not see posts from Google because I must filter them as spam
     
    Kevin McMurtrie, Dec 27, 2012
    #6
  7. On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
    > In article <>,
    > me2 <> 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
     
    Arved Sandstrom, Dec 27, 2012
    #7
  8. me2

    Sven Köhler Guest

    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
     
    Sven Köhler, Dec 27, 2012
    #8
  9. On 27.12.2012 05:46, wrote:
    > 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

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Dec 27, 2012
    #9
  10. me2

    Arne Vajhøj Guest

    On 12/27/2012 8:26 AM, Sven Köhler wrote:
    > 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.


    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, Dec 27, 2012
    #10
  11. me2

    Arne Vajhøj Guest

    On 12/27/2012 2:35 AM, Kevin McMurtrie wrote:
    > In article <>,
    > me2 <> 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
     
    Arne Vajhøj, Dec 27, 2012
    #11
  12. me2

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Dec 27, 2012
    #12
  13. me2

    Arne Vajhøj Guest

    On 12/26/2012 11:46 PM, 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
     
    Arne Vajhøj, Dec 27, 2012
    #13
  14. me2

    Sven Köhler Guest

    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.
     
    Sven Köhler, Dec 27, 2012
    #14
  15. me2

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Dec 27, 2012
    #15
  16. In article <c3WCs.31155$>,
    Arved Sandstrom <> wrote:

    > On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
    > > In article <>,
    > > me2 <> 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
     
    Kevin McMurtrie, Dec 28, 2012
    #16
  17. me2

    me2 Guest

    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
     
    me2, Dec 28, 2012
    #17
  18. me2

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Dec 28, 2012
    #18
  19. me2

    Arne Vajhøj Guest

    On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
    > In article <c3WCs.31155$>,
    > Arved Sandstrom <> 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
     
    Arne Vajhøj, Dec 28, 2012
    #19
  20. me2

    me2 Guest

    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
     
    me2, Dec 28, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Stein
    Replies:
    0
    Views:
    783
    Thomas Stein
    Oct 18, 2004
  2. Guy
    Replies:
    2
    Views:
    548
    Sid Ismail
    Dec 4, 2003
  3. =?Utf-8?B?QW5kcmV3IEhheWVz?=

    C#/Java Souce Code For ASP.NET Bandwidth/Speed Test Page Needed

    =?Utf-8?B?QW5kcmV3IEhheWVz?=, Mar 5, 2007, in forum: ASP .Net
    Replies:
    5
    Views:
    1,940
    =?Utf-8?B?QW5kcmV3IEhheWVz?=
    Mar 7, 2007
  4. Replies:
    0
    Views:
    441
  5. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    432
    Fredrik Lundh
    Aug 13, 2008
Loading...

Share This Page