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

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


Attachments

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?

Note You need to log in before you can comment on or make changes to this bug.