thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark <static.void....@gmail.com>
Subject Re: Generic questions
Date Wed, 19 Jun 2013 16:00:08 GMT
Thanks for the input. So this is what I gathered from your response and some investigating.
I'm hoping others can chime in with their thoughts.

1) Ill probably want to use either BufferedTransport or FramedTransport. Still not quite sure
on what should be considered before using one over the other. I did some preliminary testing
with a ruby server/client and I found that BufferedTransport seemed to outperform FramedTransport.

2) BinaryPrototocol is wasteful so other implementations should be considered. I'm sure JSON
falls into that category too but is a good candidate for testing/debugging. So that pretty
much leaves Compact as the choice of protocol. I also found this to support your argument
about Binary being wasteful (http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html)

3) The SimpleServer should probably only be used for examples, tests etc. That leaves me with
the choice of Threaded or NonBlocking but I'm still unsure of what should be considered before
choosing one over the other. I also did some testing with the latest ruby gem and found the
ThinHttpServer to perform terribly against the other versions. Not quite sure why anyone would
want to use this.

Do Thrift clients maintain a connection to a server? If so, how does one load balance between
a pool of servers?

Thanks again

On Jun 19, 2013, at 6:25 AM, Ben Craig <ben.craig@ni.com> wrote:

> Here are the answers for C++.  Often, they apply to the other languages, 
> but I know that some languages (Java) give some of the servers different 
> names.
> 
> 1) The "raw" transports like TSocket do no buffering.  BufferedTransport 
> and FramedTransports are more like transport decorators. BufferedTransport 
> adds buffering, but it doesn't change the byte sequence that goes over the 
> raw transport.  FramedTransports add buffering, and whenever someone calls 
> flush() on the transport, FramedTransport will first write out the size of 
> the buffered data, then follow it up with the data.  So FramedTransport 
> changes what bytes are sent / parsed on the raw transport.
> 2) Very little documentation that I've found.  Binary tends to be 
> relatively straightforward, but it isn't doing an awesome job at 
> optimizing for message size.  Compact is a bit trickier, but I haven't 
> looked at it all that much.  I don't know if there are downsides to using 
> compact or not.  JSON is almost certainly larger than binary or compact, 
> but it should be easier to debug.
> 3) In C++, the simple server only permits one connection.  The threaded 
> server allocates one thread per connection.  The nonblocking server is 
> strange, and I haven't really used it yet.  I know that it requires a 
> framed transport, and requires you to use something socket based because 
> it has a select loop in it.  It claims to be high performance.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message