Fwd: About HTTP/2 priority

[Shengtuo Hu]

Hi Valentin,

Do you mean that because NGINX is fast enough and the network environment
is good, so NGINX can process only one request at every moment?

My purpose is to figure out the priority mechanism. It seems only
when there is limited capacity for sending, priority will be used to
select streams for transmitting frames. I misunderstood this part before.

Your explanation is quite clear. I will try to do a real benchmark. Thank
you.

Best regards,

Shengtuo Hu

On Tue, Oct 27, 2015 at 9:55 PM, Valentin V. Bartenev <vbart at nginx.com>
wrote:

> On Tuesday 27 October 2015 17:33:22 Shengtuo Hu wrote:
> > Hi,
> >
> > I got some problems when testing priority feature in Nginx 1.9.5.
> >
> > Here is the detail about my test:
> > https://gist.github.com/h1994st/f21cdb7125a65c8f7182
> >
> > Why are the response sequence from these two servers different?
> >
> > The response sequence of nghttp server is my expected result.
> >
> > Could you tell me the related part in nginx source code? I want to figure
> > out this problem. It has bothered me for a long time.
> >
>
> The response sequence exactly matches the request sequence, which isn't
> surprising if we consider the sizes of files.
>
> When NGINX receives the request for "/" (stream ID 13), there's no other
> active streams at the moment, and nginx write the whole response down to
> the socket.  Then nginx receives the request for "/main.css" and since
> there no other active streams, nginx starts processing it.  Because the
> file is also very small, the whole response is written to the socket,
> again.  The same happens to other requests.  In your synthetic test case
> there's just no concurrency at all, at every moment from the server point
> of view there's either one or zero active streams.
>
> I'd suggest you to do a real benchmark with real website over real
> network (or at least emulate it using netem).  I did, and found that
> nginx is the fastest HTTP/2 webserver at the moment in terms of first
> painting and page load times.
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20151027/a15a0aef/attachment.html>