thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wang, Yongkun | Yongkun | BDD" <yongkun.w...@mail.rakuten.com>
Subject RE: Performance drops seriously when using bi-directionaly RPC
Date Wed, 22 Feb 2012 01:40:53 GMT
Joel,

Thank you very much for check my demo.

Yes, the pollingInterval is not necessary. I have defaulted it to 0, so it is equal to:

    while ( processor.process( protocol, protocol ) == true ) {}

This is using for receiving the data on client from server.

My problem is, even there is no data from server to client, the throughput of sending messages
from client to server drops seriously.

I need to remove this while loop on client side, and stop getting the "Client" and starting
the Distributor on server side, then throughput of client to server can be resumed.
Throughput is still worse if I just remove either side.

I have tried java socket, the throughput of client to server doesn't drop if I start thread
to be ready to send data from client to server with the same connection.

So I guess this might be a implementation issue of Thrift. Maybe the block on socket read,
I see that the SO_TIMEOUT is set to 0.

Cheers,
Kun

-----Original Message-----
From: Joel Meyer [mailto:joel.meyer@gmail.com] 
Sent: Wednesday, February 22, 2012 9:35 AM
To: user@thrift.apache.org
Subject: Re: Performance drops seriously when using bi-directionaly RPC

Hi Kun,

I haven't looked in depth at your implementation, but I do see that you're sleeping for "pollingInterval"
milliseconds between processing messages, if I parsed the code correctly:

    while (true) {

      try {

        while (processor.process(protocol, protocol) == true) {



          try {

            if ( this.pollingInterval > 0 ) {

              Thread.sleep(this.pollingInterval);

            }

          } catch (InterruptedException ie) {

            ie.getMessage();

            break;

          }



        }

      }

I believe that's unnecessary, as the thread will block on socket read anyway, until another
message is available. The default pollinginterval seems to be 100ms, so I'd expect your max
throughput is capped at 10 messages/sec or so.

Cheers,
Joel

On Mon, Feb 13, 2012 at 11:21 PM, Wang, Yongkun | Yongkun | BDD < yongkun.wang@mail.rakuten.com>
wrote:

> Hi, guys****
>
> ** **
>
> I am trying to the following case with thrift in java:****
>
> ** **
>
> Client sends data to server, then server sends back a message by the 
> same connection (TTransport). ****
>
> Server should be able to send back the message at any time, so I 
> cannot use “piggy back” when client sends data.****
>
> ** **
>
> I wrote a java application with bi-directional RPC, with the reference 
> of Joel Meyer's excellent example 
> (https://github.com/JoelPM/BidiThrift).****
>
> ** **
>
> On server side:****
>
> One thread starts the thrift server (TSimpleServer), another thread 
> will capture the connection from client, and send data to client;****
>
> ** **
>
> On client side:****
>
> One thread will do RPC to server to send data, and another thread will 
> simulate a thrift server, waiting for the data from server side.****
>
> ** **
>
> But I find that the performance drops seriously (more than 50%) even 
> when the server does not send any data.****
>
> ** **
>
> I am checking the reason. I feel that maybe there are some blocking 
> until timeout. Maybe on client side, the thread with following code to 
> simulate a thrift server and receive the data from server side, may be 
> blocked when no data is coming:****
>
> ** **
>
> while ( true ) {****
>
>     while ( processor.process( protocol, protocol ) == true ) {}****
>
> }****
>
> ** **
>
> Maybe the non-blocking server (TNonblockingServer) does not have the 
> performance issue. But I cannot use the non-blocking server.****
>
> ** **
>
> I attached a sample code in this email.****
>
> ** **
>
> Any suggestions would be appreciated.****
>
> Thank you very much.****
>
> ** **
>
> Regards,****
>
> Kun****
>
Mime
View raw message