16

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.
Community
  • 1
  • 1
nikib3ro
  • 20,366
  • 24
  • 120
  • 181
  • 1
    Which version of ASP.NET are you using? `HttpRequest` object doesn't have such a method (see [here](http://msdn.microsoft.com/en-us/library/system.web.httprequest_methods.aspx)). Is it an extension method? – Saeed Neamati Nov 22 '11 at 05:24
  • I'm compiling for .NET Framework 3.5. There is such method, but it's private; that's the reason you are not seeing it in MSDN documentation... [look here](http://www.google.com/url?sa=t&rct=j&q=fillinformcollection&source=web&cd=4&ved=0CEAQFjAD&url=http%3A%2F%2Ftypedescriptor.net%2FSystem.Web.HttpRequest.FillInFormCollection()&ei=NxjMTvPoAsOviALXj_n2Cw&usg=AFQjCNFwp9GwDHezbcBkf8sVf-rDT_DMpQ&cad=rja) – nikib3ro Nov 22 '11 at 21:50
  • Is there anything unusual about the slow page? Are there several request parameters or a very large ViewState being passed back? – Garrett Vlieger Dec 02 '11 at 18:50
  • @GarrettVlieger just updated question with more details – nikib3ro Dec 02 '11 at 19:03
  • 1
    That's very strange. Unfortunately it doesn't seem like there's much evidence to point to any cause. If it's nothing in your code or the request, it could be something server-related. If you haven't done so already, try running it on a different server. – Garrett Vlieger Dec 02 '11 at 19:23
  • 1
    What's the content type of the form being sent to the server? Using ILSpy, I can see that the method does something different if the form is "application/x-www-form-urlencoded" compared to "multipart/form-data" – dash Dec 05 '11 at 22:22
  • In fact, if the form is "application/x-www-form-urlencoded" then FillInFormCollection will call GetEntireRawContent, suggesting that GetEntireRawContent is your bottleneck. – dash Dec 05 '11 at 22:23
  • 2
    So the next thing to do is break out a tool like ANTS or the Visual Studio Performance Profiler and take a look at where the framework is spending all of it's time. – dash Dec 05 '11 at 22:28
  • 1
    Question are you going across http:// or https:// I wonder if there is a Principal issue here.. it's probably something very simple – MethodMan Dec 06 '11 at 17:54
  • Can you post the source aspx for your login page? Also, have you checked the event log? As the login page is probably the first page people hit, the site isn't being reloaded is it? – dash Dec 07 '11 at 22:42
  • What is involved in a user login? Obviously, if it's hitting a database or something, that could be the issue. – jhsowter Feb 09 '12 at 03:15
  • 1
    I am having a similar issue in my asp.mvc app, takes a little over 1.5 seconds for System.Web.HttpRequest.FillInFormCollection() to run which seems pretty ridiculous – Slee Feb 14 '12 at 18:00

1 Answers1

15

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.

Slee
  • 27,498
  • 52
  • 145
  • 243