[
https://issues.apache.org/jira/browse/TS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312968#comment-15312968
]
Leif Hedstrom commented on TS-4324:
-----------------------------------
I thought / assumed the issue was not around waiting for content here, but
making sure we don't do these very unfortunate 9 byte frames. What gaff is
different, in that if there's nothing more to read from origin, we should flush
and send what we got as a frame (but, might have a little bit of wait time
there?).
> Inefficient way of transferring data frames
> -------------------------------------------
>
> Key: TS-4324
> URL: https://issues.apache.org/jira/browse/TS-4324
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2
> Reporter: Bryan Call
> Assignee: Masaori Koshiba
> Fix For: 7.0.0
>
>
> ATS transfers data 8K - 9 bytes (http/2 header size) and then sends the 9
> bytes is couldn't write in a new frame that only has 9 bytes. This also
> happens if you bump up the buffer size to 16K.
> {code}
> [ 1.036] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.036] recv DATA frame <length=9, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=9, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=8183, flags=0x00, stream_id=13>
> [ 1.259] recv DATA frame <length=9, flags=0x00, stream_id=13>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
