Hi,

We have found one issue with proposed solution. The issue is that now SETTINGS frame will be send after SYN_REPLY frame. Though, it does not violate SPDYv2 protocol, it can be easily fixed by changing:
@@ -1662,7 +1662,7 @@ ngx_http_spdy_send_settings(ngx_http_spdy_connection_t *sc)
 
     buf->last = p;
 
-    ngx_http_spdy_queue_frame(sc, frame);
+    ngx_http_spdy_queue_blocked_frame(sc, frame);
 
     return NGX_OK;
 }

BR/ Yury


2013/7/6 Yury Kirpichev <ykirpichev@gmail.com>
Yes, we did such modification in our test environment and it is working well so far.
Moreover, it showed good results in case of intermixed requests with low and high priority are handled.

BR/ Yury


2013/7/5 Valentin V. Bartenev <vbart@nginx.com>

On Wednesday 26 June 2013 12:34:17 Yury Kirpichev wrote:
> Hello,
>
> Thanks for analysis and explanation.
> Then how about the following workaround -
> - queue blocked frames at the begining of queue in FIFO order.
> (just remove from ngx_http_spdy_queue_blocked_frame the code:
>  if (frame->priority >= (*out)->priority) {
>             break;
>         }
> )
>
> - queue non-blocked frames after blocked in priority order:
> static ngx_inline void
> ngx_http_spdy_queue_frame(ngx_http_spdy_connection_t *sc,
>     ngx_http_spdy_out_frame_t *frame)
> {
>     ngx_http_spdy_out_frame_t  **out;
>
>     for (out = &sc->last_out; *out *&& !(*out)->blocked*; out =
> &(*out)->next)
>     {
>         if (frame->priority >= (*out)->priority) {
>             break;
>         }
>     }
>
>     frame->next = *out;
>     *out = frame;
> }
>
> Do you foresee any obvious drawback of such approach?
>
[..]

At first glance I don't.  Indeed it can be a better strategy, particularly
since the SYN_STREAM frames are usually small.

Have you tested it already?

  wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel