> -----Original Message-----
> From: Stefan Eissing [mailto:[email protected]]
> Sent: woensdag 25 november 2015 10:05
> To: [email protected]
> Subject: Re: H2 stream dependencies
>
> The execution order of requests is not defined by the protocol and up to
the
> server implementation. As you noticed, one major factor is the mpm active
in
> httpd, influencing how, and if, requests are handled in parallel.
>
> Even setting dependencies and priorities on streams will not make this
fully
> deterministic, as I tried to explain.
>
> The case of a prefork mpm without further configuration is an extreme
case.
> Prefork, intended to allow a single thread processing model, has by
default
> 1(!) http/2 worker. That means that requests are worked on one at a time.
A
> blocking request may therefore block all later requests. This is not how
> HTTP/2 is supposed to work, but it is how prefork is.
>
> You can configure more H2Workers and have multiple threads even in
> prefork. But you need to be sure that the application you run can live
with
> multi-threading.
>
> Without knowing your client that well, it seems to assume that requests
are
> processed one after the other. And rely on that. This assumption no longer
> holds in HTTP/2. If you send 2 requests, responses may arrive in any order
or
> interleaved, not matter what you specify for priority. Relying on the
exposed
> behaviour of a certain implementation under certain configuration is
> probably the least that you'd want.
Ok... I applied a stopgap solution in Subversion until we switch to a
smarter request later on in the 1.10 devcycle. With that my number of failed
tests over h2 dropped to just 5. (Of the several thousand Subversion test
scenarios).
* 2 of these are related to HTTP/1.1 status lines where we no longer have
access to the reason field.
* 2 others somehow run against an httpd limit when I only configure 16
threads (while running 4 tests in parallel; each with potentially multiple
connections)
* and the last one is an interesting crash in the serf code.
With another one of my Subversion hats on I'm wondering what we as a module
should do for optimal performance here. We can deliver data quite fast (as
it is essentially just local file-io) and the threading overhead could be
quite large. Are there any guidelines for this at this time?
Perhaps some of this should be applied to mod_dav directly instead of
mod_dav_svn.
Bert
