You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Ben Craig (JIRA)" <ji...@apache.org> on 2013/11/05 17:58:17 UTC

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

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

Ben Craig commented on THRIFT-2252:
-----------------------------------

This could be done, but it would need to be implemented as a separate protocol.  Only this protocol would look at the API ID.

> 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)