[jira] [Comment Edited] (THRIFT-2252) Optimize the overhead of the tag message of the request

["Jens Geyer (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815226#comment-13815226 ] 

Jens Geyer edited comment on THRIFT-2252 at 11/6/13 8:04 PM:
-------------------------------------------------------------

{quote}
... more options ...
{quote}

The function names are used to build up a map to find the correct processing function, as you already found out. So the consequent solution from perfomance point of view would be changing the internal representation of the map key to int too. This way the ID could be used directly and does not need to be mapped. But ... and it's a big but ... doing so would either involve a mapping for ALL other protocols (thus degrade performance for everyone else), or - if you don't map - it breaks compatibility with existing Thrift clients/servers which send/expect strings.

The point where I agree is that this design decision should have been made from the start and in a way similar to the field IDs, but the guys at FB obviously decided otherwise. For a more detailed explanation I recommend the [Thrift whitepaper|http://thrift.apache.org/static/files/thrift-20070401.pdf], specifically section 7.3.



was (Author: jensg):
{quote}
... more options ...
{quote}

The function names are used to build up a map to find the correct processing function, as you already found out. So the consequent solution from perfomance point of view would be changing the internal representation of the map key to int too. This way the ID could be used directly and does not need to be mapped. But ... and it's a big but ... doing so would either involve a mapping for ALL other protocols (thus degrade performance for everyone else), or - if you don't map - it breaks compatibility with existing Thrift clients/servers which send/expect strings.

The point where I agree is that this design decision should have been made from the start, but the guys at FB obviously decided otherwise. For a more detailed explanation I recommend the [Thrift whitepaper|http://thrift.apache.org/static/files/thrift-20070401.pdf], specifically section 7.3.


> Optimize the overhead of the tag message of the request
> -------------------------------------------------------
>
>                 Key: THRIFT-2252
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2252
>             Project: Thrift
>          Issue Type: Improvement
>            Reporter: George Cao
>              Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of  a tag message(TMessage) and the API arguments.
> This tag message includes the API name(method name), message type and a sequence ID. 
> Compare to the API arguments which usually are some structure data like integers, the tag message will cause a lot of overhead because of the API name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes and the API arguments only takes 4 bytes.
>  
> Even worse if we support multiplexing, because we need append additional service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?  Then we can avoid using the verbose string names.



--
This message was sent by Atlassian JIRA
(v6.1#6144)