Bug 14644 - Simultaneous web requests
Summary: Simultaneous web requests
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: master
Hardware: PC Windows
: Normal normal
Target Milestone: Untriaged
Assignee: Paolo Molaro
Depends on:
Reported: 2013-09-11 10:17 UTC by Yuri
Modified: 2014-01-06 09:00 UTC (History)
7 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 14644 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Comment 2 Yuri 2013-09-20 17:26:09 UTC
If you don't have many CPU cores and many threads then the time switching between threads affects performance.
Comment 3 Yuri 2013-09-20 17:28:22 UTC
The actual problem is not less than a second or more than a seconds. It is why 35 seconds? That cannot be caused by switching between threads.
Comment 4 Marek Safar 2013-09-24 08:14:45 UTC
- using ThreadPool.SetMinThreads(40, 8); is bad, it does some weird things on Mono. Foe example decreasing number of worker thread to less than CPU count increases the test performance. Don't call it and use default TP settings.

With defaults settings I tried values 20, 30, 40, 50, 60, 70 and there is gradual slowdown. I think the web request is performing badly because it's locking right, left and center. Also WebConnection::SendRequest and similar could be written to require less additional threads.
Comment 5 Miguel de Icaza [MSFT] 2013-09-24 08:58:29 UTC
Hey guys,

Isn't this just the threadpool's slow start?  Where we take an extra second to start up any additional thread?

This code is there to prevent code accidentally spawning hundreds of threads very quickly.
Comment 6 Marek Safar 2013-09-24 09:01:22 UTC
No, this is not about slow start. The requests are fired quickly but handled slowly and the process gets slower as the number of requests increases.
Comment 7 Paolo Molaro 2013-09-24 09:42:18 UTC
I committed a fix to master that should fix this issue, leaving bug open until
the change trickles down to products.
Comment 8 Marek Safar 2013-09-24 10:17:42 UTC
I still see same patter just several seconds faster.

10 sim requests ~2 seconds slowset
50 sim requests ~8 seconds slowest
100 sim request ~16 seconds slowest
Comment 9 Paolo Molaro 2013-09-24 12:03:22 UTC
On my system at least the new code is several times faster, 100 sim goes from 40+ seconds to 6-7.

A good chunk of the remaining time is contended locks in the web request pipeline:

        Lock object 0x7fc7e40d7460: 107 contentions
                1.617819 secs total wait time, 0.020071 max, 0.015120 average
        96 contentions from:
                System.Net.HttpWebRequest:BeginGetResponse (System.AsyncCallback,object)
                System.Net.HttpWebRequest:GetServicePoint ()
                System.Net.ServicePointManager:FindServicePoint (System.Uri,System.Net.IWebProxy)
                System.Net.ServicePointManager:RecycleServicePoints ()
                (wrapper unknown) System.Threading.Monitor:FastMonitorEnterV4 (object,bool&)
                System.Threading.Monitor:Enter (object,bool&)
        11 contentions from:
                System.Net.HttpWebRequest:GetResponse ()
                System.Net.HttpWebRequest:BeginGetResponse (System.AsyncCallback,object)
                System.Net.HttpWebRequest:GetServicePoint ()
                System.Net.ServicePointManager:FindServicePoint (System.Uri,System.Net.IWebProxy)
                (wrapper unknown) System.Threading.Monitor:FastMonitorEnterV4 (object,bool&)
                System.Threading.Monitor:Enter (object,bool&)
        Lock object 0x7fc7e40919c8: 99 contentions
                1.321992 secs total wait time, 0.014954 max, 0.013353 average
        99 contentions from:
                (wrapper remoting-invoke-with-check) System.Net.HttpWebRequest:.ctor (System.Uri)
                System.Net.HttpWebRequest:.ctor (System.Uri)
                System.Net.GlobalProxySelection:get_Select ()
                System.Net.WebRequest:get_DefaultWebProxy ()
                (wrapper unknown) System.Threading.Monitor:FastMonitorEnterV4 (object,bool&)
                System.Threading.Monitor:Enter (object,bool&)
        Lock object 0x7fc7e41f0d38: 97 contentions
                0.576336 secs total wait time, 0.008244 max, 0.005942 average
        97 contentions from:
                System.Net.WebClient:GetWebResponse (System.Net.WebRequest)
                System.Net.HttpWebRequest:GetResponse ()
                System.Net.HttpWebRequest:BeginGetResponse (System.AsyncCallback,object)
                System.Net.ServicePoint:SendRequest (System.Net.HttpWebRequest,string)
                (wrapper unknown) System.Threading.Monitor:FastMonitorEnterV4 (object,bool&)
                System.Threading.Monitor:Enter (object,bool&)
Comment 11 Yuri 2013-10-22 15:45:33 UTC
Are you going to look for another solution then?
Comment 12 Miguel de Icaza [MSFT] 2014-01-06 09:00:18 UTC
Paolo, could you review the reason why your patch introduced a regression and address that bug?