threads and system calls

Discussion in 'Ruby' started by snacktime, Aug 6, 2006.

  1. snacktime

    snacktime Guest

    I'm curious how ruby threads would do for a threaded network server.
    Will reading/writing sockets in one thread block other threads? In
    this application clients connect to the server via ssl and a simple
    line protocol. They send requests to the server, and the server in
    turn makes https connections to yet another server, gets the response,
    and sends it's own response back to the client. Clients can send
    multiple requests and stay connected as long as they want.

    The servers that the application makes an https connection to speak
    5-6 different protocols. Right now we have one application written in
    perl that speaks 2 of them, and one in python's twisted that speaks
    another. I want to consolidate everything into one application so I'm
    evaluating my options. Perl is ok, no real complaints. Twisted is
    amazingly fast for how few resources it consumes, but the code is
    rather complicated and I'm not sure it's worth the extra performance.
    I've used ruby for a while now but haven't used ruby threads and not
    sure what kinds of issues I would run into with an application like
    this. The application would need to be able to handle 20-30
    concurrent clients each sending one request every 3-4 seconds. So
    figure 40 or so ssl connections per second at the most plus the
    connected clients, which will usually stay connected for long periods
    of time.

    Any advice or suggestions would be welcome.
    snacktime, Aug 6, 2006
    #1
    1. Advertising

  2. snacktime wrote:
    > I'm curious how ruby threads would do for a threaded network server.
    > Will reading/writing sockets in one thread block other threads? In
    > this application clients connect to the server via ssl and a simple
    > line protocol. They send requests to the server, and the server in
    > turn makes https connections to yet another server, gets the response,
    > and sends it's own response back to the client. Clients can send
    > multiple requests and stay connected as long as they want.
    >
    > The servers that the application makes an https connection to speak
    > 5-6 different protocols. Right now we have one application written in
    > perl that speaks 2 of them, and one in python's twisted that speaks
    > another. I want to consolidate everything into one application so I'm
    > evaluating my options. Perl is ok, no real complaints. Twisted is
    > amazingly fast for how few resources it consumes, but the code is
    > rather complicated and I'm not sure it's worth the extra performance.
    > I've used ruby for a while now but haven't used ruby threads and not
    > sure what kinds of issues I would run into with an application like
    > this. The application would need to be able to handle 20-30
    > concurrent clients each sending one request every 3-4 seconds. So
    > figure 40 or so ssl connections per second at the most plus the
    > connected clients, which will usually stay connected for long periods
    > of time.
    >
    > Any advice or suggestions would be welcome.


    Look at EventMachine (Rubyforge) for a ruby implementation of something
    much like Twisted at least as fast and relatively efficient too. EM
    supports SSL, can easily handle multiple protocols and isn't very hard
    to use. The latest (unpublished) versions support thread-pools and
    locally-blocking functions (like Twisted's Deferreds) if you need them.
    We don't have a large library of standard protocols like Twisted yet,
    but they are coming.

    --
    Posted via http://www.ruby-forum.com/.
    Francis Cianfrocca, Aug 6, 2006
    #2
    1. Advertising

  3. snacktime

    snacktime Guest

    >
    > Look at EventMachine (Rubyforge) for a ruby implementation of something
    > much like Twisted at least as fast and relatively efficient too. EM
    > supports SSL, can easily handle multiple protocols and isn't very hard
    > to use. The latest (unpublished) versions support thread-pools and
    > locally-blocking functions (like Twisted's Deferreds) if you need them.
    > We don't have a large library of standard protocols like Twisted yet,
    > but they are coming.


    I had actually been keeping an eye on EventMachine, just hadn't taken
    the time to play around with it yet. Do you mean that you can do
    something similar to twisted's defertothread? ie, calling local
    blocking functions and have them run in the thread pool and be able to
    specify a callback of some type?
    snacktime, Aug 6, 2006
    #3
  4. snacktime

    snacktime Guest

    Ok I grabbed the source from the svn repo and am looking through it.
    Looks like there are enough samples and code there to get an idea of
    how it all works.
    snacktime, Aug 6, 2006
    #4
  5. snacktime wrote:
    > Ok I grabbed the source from the svn repo and am looking through it.
    > Looks like there are enough samples and code there to get an idea of
    > how it all works.


    Sounds like you figured it out. You get the defertothread-like behavior
    with EventMachine#defer and there is a code sample in the Rdoc. Very
    simple.

    The Deferrable pattern is a separate feature that doesn't require thread
    pools to work. Deferrable is illustrated with the TcpConnectTester in
    the protocols directory, and it's also very simple although there isn't
    much documentation of the pattern yet.

    The idea here is identical to Twisted's Deferred object. You start with
    an ordinary class of your own, like a network-protocol handler, that is
    written to receive normal EventMachine events. Include
    EventMachine::Deferrable in your class and then instantiate your objects
    as you normally would. The Deferrable module adds several methods to
    your class: #callback, #errback, and #set_deferred_status(status,
    *args). As long as your object exists in memory, your program can add
    code blocks to it via one or more calls to callback and errback, and set
    the object's "status" (notionally, the outcome of the deferred operation
    that it performs) via #set_deferred_status. If the status is :succeeded,
    then all of the code blocks added via #callback are automatically called
    in order with the arguments passed to #set_deferred_status. If status is
    :failed, the #errback chain is called. As with Twisted, you can call
    #callback and #errback even after the operation status is known.

    But in your OP, you didn't say anything about needing Deferrables or
    locally-blocking operations. Sounds like you're trying to do a
    plain-vanilla multi-platform network server. If you need the newer
    stuff, let me know and I'll publish a new release and add some more
    docs.

    The big problem that Windows users have with EM is that it's a compiled
    extension. Let me know if you have trouble with it. I just made a win32
    binary gem the other day for EM version 0.7.0. I'd like to release a
    pure-Ruby version of EM someday soon, although there are currently two
    problems with it: it's about half as fast as the extension (although
    that is probably plenty fast enough for most applications), and it
    requires a recent snap of Ruby 1.8.5 to get needed improvements to
    nonblocking I/O.

    --
    Posted via http://www.ruby-forum.com/.
    Francis Cianfrocca, Aug 6, 2006
    #5
  6. snacktime

    snacktime Guest

    Am I correct that version_0 in the repository is the current branch
    you are releasing from? I was just playing around with creating a
    simple line handling protocol using some of the code you had in
    another directory.

    Also, any suggestions on how to implement a pool of database
    connections that can be reused?
    snacktime, Aug 7, 2006
    #6
  7. On 8/6/06, snacktime <> wrote:
    > Am I correct that version_0 in the repository is the current branch
    > you are releasing from? I was just playing around with creating a
    > simple line handling protocol using some of the code you had in
    > another directory.
    >
    > Also, any suggestions on how to implement a pool of database
    > connections that can be reused?
    >
    >


    Version_0 is the current release branch. The other ones are
    experimental and pure-ruby branches. The obvious way to do a
    connection pool would be with Ruby's thread-safe Queue object. You
    could pull a connection off when you needed one and do the work with
    EventMachine#defer. If this doesn't make any sense, please let me
    know. It's probably worth having a connection pool implemented in a
    standard way in the library itself.
    Francis Cianfrocca, Aug 7, 2006
    #7
    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. Honne Gowda A
    Replies:
    2
    Views:
    873
    Karl Heinz Buchegger
    Oct 31, 2003
  2. andy6
    Replies:
    2
    Views:
    757
    andy6 via DotNetMonster.com
    Jun 9, 2006
  3. markus
    Replies:
    22
    Views:
    665
    Dances With Crows
    Sep 22, 2004
  4. Richard Tobin
    Replies:
    24
    Views:
    788
  5. Bob
    Replies:
    5
    Views:
    260
Loading...

Share This Page