Re: delta encoding and state management

On Tue, Jan 22, 2013 at 2:46 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Tue, Jan 22, 2013 at 01:48:42PM -0800, William Chan (?????????) wrote:
>> This is an intriguing counterproposal. Perhaps we should fork the
>> thread to discuss it?
>
> maybe, yes.
>
>> I'd still like to get an answer here about what
>> folks think about the acceptability of the rough costs of stateful
>> compression.
>
> It's hard to get opinions on what is considered as "heavy", it depends
> a lot on what you're doing. In haproxy we default to 2*16kB of buffers
> plus around 1 kB of state per connection. Some people are already
> pressuring me to get rid of the 2*16kB for websocket connections so
> that they don't need 32 GB of RAM per million connection.
>
> And I know other contexts where completely buffering a 5 MB POST request
> before passing it to a server is considered fairly acceptable.
>
> One of the issue comes from the fact that no limit is suggested for how
> large a request can be, and due to this we generally have to allocate
> large amounts of resources "just in case". This is what is problematic
> with whatever is stateful. However, I do think that being able to buffer
> a full request will be acceptable for any agent (client, intermediary,
> server), because all of them have to see the full request at least once,
> and its buffers are adequately sized for this. If part of this request
> is reused for next requests, there is no need for allocating more memory
> and it's a win at the same time.
>
> What is difficult to judge is how much we need to store for compression
> states which have to be stored in addition to the request itself. As a
> rule of thumb, I'd guess that doubling the whole state is quite annoying
> but still manageable.
>
>> One issue I see in this proposal is that, as always, it is difficult
>> to predict the future. You don't know when you're parsing the document
>> when you'll discover a new resource to request.
>
> I don't understand what you mean here.
>
>> How long do you delay
>> the resource request in order to consolidate requests into a load
>> group? The same thing is even more true for response headers.
>
> I never want to delay anything, delays only do bad things when we
> try to reduce latency.

One of us has the wrong mental model for how the proposal would work.
Let's figure this out.

Let's say the browser requests foo.html. It receives a response packet
for foo.html, referencing 1.js. 5ms later, it receives packet 2 for
foo.html which references 2.js. 5ms it receives packet 3 for foo.html
which references 3.js. And so on. You say no delays. So does this mean
each "group" only includes one object each time?

And now let's ignore the 5ms delays. Consider how WebKit works. Let's
say WebKit has all of foo.html. It starts parsing it. It encounters
1.js. It immediately sends the resource request to the network stack.
It hasn't parsed the full document yet, so it doesn't know if it'll
encounter any more resources. Each time it encounters a resource while
parsing the document, it will send it to the network stack (in
Chromium and latest versions of Safari, this is a separate process).
What is the network stack to do if, as you say, it should never delay
anything? If I understand correctly, each "group" would always only
include one object then.

>
> In the example I proposed, the recipient receives the full headers
> block, then from that point, all requests reuse the same headers
> and can be processed immediately (just like pipelining in fact).
>
> Concerning response headers, I'd say that you emit a first response
> group with the headers from the first response, followed by the
> response. When another response comes in, you have two possibilities,
> either it shares the same headers and you can add a response to the
> existing group, or it does not and you open a new group.

Wait, is this the critical misunderstanding? Are you maintaining state
across requests and responses? Isn't this a minor modification on the
"simple" compressor? I was assuming you were trying to be stateless.

>
> But that said, I would not spend too much energy trying to optimize
> response headers. Right now they're commonly less important because
> often accompanied with data and also because the downstream link
> generally is much bigger than the upstream one. Still that's not
> something to ditch either.
>
> Regards,
> Willy
>

Received on Tuesday, 22 January 2013 23:08:35 UTC