Maximum Concurrency when using QUIC protocol

[Xinan Lin]

Hi Group,

  I am using QUIC to make some internal performance test.
  However when I review the result I found Chrome loaded the page very similar with HTTP, restricting by the maximum concurrency(for chrome , it is 6).
   I have thought that when Chrome loaded a page through QUIC, it actually works on SPDY(quic+spdy). It should not limited by the maximum concurrency.

 My env :

• OS : ubuntu 1404, 64bit
• Chrome : 39.0,
  
• start option : chrome --incognito --enable-quic --origin-to-force-quic-on=test.site:80 http://test.site/
• 100ms latency between client and server
  

I attached the har file and a screen capture, which shows Chrome load page objects 6 by 6. 

I d like to receive any comment from anyone.

Regards,

[Ryan Hamilton]

Can you provide a net-internals dump for this? I'm pretty familiar with this code, and as far as I know we don't have an concurrently limit of 6 in there.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Gaetano Carlucci]

hi,

I have experienced the same limit (max six objects)
cheers

[Ryan Hamilton]

Please provide a net-internals trace. https://dev.chromium.org/for-testers/providing-network-details

[Xinan Lin]

Thank you for response!
 
here i attached the dump file.

regards,

[Xinan Lin]

 I also attached the events log for QUIC. chrome://net-internals/#events&q=type:QUIC_SESSION%20676077215733215289
Hope them helpful for targeting the issue.

[Ryan Hamilton]

Any chance you can export the full log? I'm curious to see the interaction between the various URL_REQUEST events and the QUIC_SESSION events.

[Ryan Hamilton]

In the mean time, at t=8886 -> t= 8937, we see 7 requests being sent in parallel. So if there is something that is throttling requests, the cap must be larger than 6.

[Ryan Hamilton]

You might consider a simple test case in which you request images.html which simply consists of, say, 25 <img src=""> tags. It looks like there's a bunch of css and js in that log. I'm not sure if those block parsing of the rest of the page.

[Xinan Lin]

I created the simple test case, as you indicated.
one index.html which including 100 image file. NO CSS and no JS.

However, the concurrency of 6 still exists ...

HAR and QUIC event dump log attached. The image file is a screen capture of the HAR file.

Regards,

[Ryan Hamilton]

Could you please export the full log as a .json file? This appears to simply be the text of the QUIC_SESSION event.

[Xinan Lin]

attached the json file.

[Ryan Hamilton]

Hm! Very curious. The way I read this, the request are being throttled above the network stack. Odd. I'll do more digging tomorrow. I wonder if something in the resource scheduler is doing the wrong thing.

Thanks for the report!

[Xinan Lin]

Hi Ryan,

 Thank you for your hint. I checked the source and I think I know the reason.

content/browser/loader/resource_scheduler.cc

Line 693

for spdy, the requests are scheduled as below(I inserted fprintf for marking)

730 if (http_server_properties.SupportsSpdy(host_port_pair)) {
731 fprintf(stderr, "QUIC_DEBUGGING, Line 731\n");  // private dbg mark
732 return START_REQUEST;
733 }

However for quic , the requests are scheduled like this :
757 if (ShouldKeepSearching(host_port_pair)) {
758 // There may be other requests for other hosts we'd allow,
759 // so keep checking.
760 fprintf(stderr, "QUIC_DEBUGGING, Line 760\n");
761 return DO_NOT_START_REQUEST_AND_KEEP_SEARCHING;
762 }

I thinks when Chrome speaks QUIC with a server, it actually speaks SPDY over QUIC. The resource scheduler should use SPDY scheduler for QUIC, not normal HTTP part.

By the way, I just changed all DO_NOT_START_REQUEST_AND_KEEP_SEARCHING to START_REQUEST for my POC test.(I only need my Chrome work as QUIC client, so no harm for me.) And it worked! I completed my POC successfully.

To repair it for normal usage, it will be your work maybe :)

Regards,

[Xinan Lin]

I hope my solution helpful for you. If you just need to complete a test, this is enough. But for normal usage, maybe you have to wait for some new update of Chrome.

regards,

[Ryan Hamilton]

Ok, this should be fixed in the most recent Chrome Canary release. Thanks for reporting the problem and helping to track it down!

[Fedor Kouranov]

Hey Xinan, what do the three phases (gray, darker blue and lighter blue) mean on the graph? I wonder what's happening in the 150-650 ms range of the fully parallel case...

[Xinan Lin]

Hi Fedor,

gray : blocking

darker blue  : waiting

lighter blue   : receiving

You can drag the har file to http://www.softwareishard.com/har/viewer/. I capture the screen from that site.

regards,

[Fedor Kouranov]

Gotcha, thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.