[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814273#comment-13814273
]
Jens Geyer commented on THRIFT-2252:
------------------------------------
Regarding multiplex, there is no fixed rule how to prefix each of the
multiplexed services, so these can be quite short if you want.
Regarding function names: As they are used internally at several places the
protocol would have to map the names back and forth during serialization, thus
it would need to know the mapping, thus it has to be (at least) made accessible
from the generated processing code to the outside. There are some more options,
but they are either adding unnecessary overhead for all other protocols or
would break compatibility big time, IMHO. So I'm not completely sure about
this, altough I agree to the rationale behind the question.
> 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)
