System.Web.HttpRequest.FillInFormCollection() and System.Web.HttpRequest.GetEntireRawContent() very slow

Question

I've been following performance of my website and out of all slow-executing code (>1s), more than 90% is because of System.Web.HttpRequest.GetEntireRawContent() (called by System.Web.HttpRequest.FillInFormCollection())

Is this normal for ASP.NET sites... to sometimes spend more than 10 seconds in FillInFormCollection method (obviously it's called from System.Web.UI.Page.PerformPreInit())?

Or there is a way to fix this problem?

I'm compiling for .NET Framework 3.5.

Page I'm mostly having trouble is Login page, although there is nothing unusual about it - two TextBoxes, Checkbox for RememberLogin and Login button. Request.ContentLength is around 5KB (I've logged Request.Form.ToString() - found nothing unusual). I've performed lots of tracing (were expecting huge POSTs) and debugging but couldn't find any rational reason for FillInFormCollection to take more than 10 seconds (I once had extreme example with 250 seconds). I've even tried slowing down my connection with Fiddler, but couldn't reproduce the problem.

EDIT: Thanks for all the comments guys. I've continued pursuing this issue... if it gets solved at least it'll save other people quite some time ;). Here are answers to some of the questions.

1. It's plain HTTP (not HTTPS), 0 errors in Log (funny thing is that requests actually get completed ;)
2. Site is not being loaded when user hits Login.aspx. Site is actually working pretty good 99% of the time (handles around 40 million HTTP requests per week with AVG CPU utilization below 10%)
3. It's definitely application/x-www-form-urlencoded - ASP.NET Forms (runat=server) get submitted that way. The only thing I don't understand is why .NET needs >10 seconds to read POST that's less than 6KB.
4. The only rational conclusion I came up with (so far) is -> customers accessing site from really slow connections (remember GPRS?). But I would really like to explore all other options rather than just resort to "it's user connection". And if that was the case - I expect I would be seeing similar thing happening for user on every page.
5. Just hoping it's not something like this: IIS 6.0 Server Too Busy HTTP 503 Connection_Dropped DefaultAppPool
6. Got referred to this page: Identifying Slow HTTP Attack Vulnerabilities on Web Applications It is possible that this is happening.

Answer 1

Here is what I found to be the problem, or should I say cause, of my application showing poor performance on the method: System.Web.HttpRequest.FillInFormCollection()

It seems the System.Web.HttpRequest.FillInFormCollection() starts as soon as it gets the beginning of the data being submitted to the form and completes once the last bit of data has been received. If my user has a poor connection it can take a long time for this information to be completely submitted. Hence the long times for this method.

I used a bandwidth limiter on my local machine and was able to reproduce consistent results that were in line with the varying speeds I tested at, the slower the connection speed the longer the System.Web.HttpRequest.FillInFormCollection() took to run.

Unless you are getting complaints that your web site is not working you are probably just looking at code run by users with crappy connections.