You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Bryan Call (JIRA)" <ji...@apache.org> on 2016/04/05 16:46:25 UTC
[jira] [Comment Edited] (TS-4324) Inefficient way of transferring
data frames
[ https://issues.apache.org/jira/browse/TS-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15226390#comment-15226390 ]
Bryan Call edited comment on TS-4324 at 4/5/16 2:46 PM:
--------------------------------------------------------
When I bumped the buffer to 16K I saw 16K - 9 bytes for the first frame and then 9 bytes for the second frame. I think there might be more to it then the content chunking size.
I was awhile ago, so I it needs to be investigated again.
was (Author: bcall):
When I bumped the buffer to 16K I saw 16K - 9 bytes for the first frame and then 9 bytes for the second frame. I think there might be more to it then the content chunking size.
> 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
> Fix For: 6.2.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)