search

reaktivity / nukleus-http.java

HTTP Nukleus Implementation
Apache License 2.0
0 stars 8 forks source link

Performance: improve flow control of response when acting as a server #31

Open cmebarrow opened 7 years ago

cmebarrow commented 7 years ago

This can be reproduced by running test case org.reaktivity.nukleus.http.internal.streams.rfc7230.server.FlowControlIT.shouldFlowControlResponseWithContentLength(). This test case shows the HTTP nukleus acting as a server and responding to a request with a response with content length, with the client-side initial window set to 9 (so 2 less tthan the response content length). A trace of the relevant frames suggests we are unnecessarily fragmenting the encoded response:

C:\Users\Chris\Git\reaktivity\nukleus-http.java>java -jar C:\Users\Chris\Git\reaktivity\command-log.java\target\command-log-develop-SNAPSHOT.jar -d target\nukleus-itests |grep -E "http [<-][->] source"
[http -> source]        [0x0000000000000000] BEGIN [0x0000007074746804] [0x26273a0000000000]
[http <- source]        [0x0000000000000000] WINDOW [9]
[http -> source]        [0x0000000000000000] DATA [9]
[http <- source]        [0x0000000000000000] WINDOW [9]
[http -> source]        [0x0000000000000000] DATA [9]
[http <- source]        [0x0000000000000000] WINDOW [9]
[http -> source]        [0x0000000000000000] DATA [9]
[http <- source]        [0x0000000000000000] WINDOW [9]
[http -> source]        [0x0000000000000000] DATA [9]
[http <- source]        [0x0000000000000000] WINDOW [9]
[http -> source]        [0x0000000000000000] DATA [3] (remainder of headers)
[http -> source]        [0x0000000000000000] DATA [6] (content)
[http <- source]        [0x0000000000000000] WINDOW [3]
[http -> source]        [0x0000000000000000] DATA [3]  (content)
[http <- source]        [0x0000000000000000] WINDOW [6]
[http -> source]        [0x0000000000000000] DATA [2] (last 2 bytes of content)
[http <- source]        [0x0000000000000000] WINDOW [3]
[http <- source]        [0x0000000000000000] WINDOW [2]

Since the response headers are of size 39 bytes, the first 6 DATA frames (of lengths 9, 9, 9, 9, 3) contain the encoded headers. The inefficiency is arising from the fact that we send the last three bytes of the encoded headers and the first few bytes of the content in separate data frames. We should combine them into a data frame consuming all available window (i.e. 9 bytes) in order to reduce the overall number of data and window frames going back and forth.

jfallows commented 6 years ago

@cmebarrow we can close this if WINDOW frames are no longer fragmented, otherwise it likely qualifies as a performance bug.