2

We have a Asp.net MVC 3 application with 3 areas, Unity dependency injection, about 20 routes. The total time to render the page is very inconstant. The biggest problem seems to be the amount of time it takes to start the action method within the controller. Even when viewing the same url. Sometimes the action is started within 100 milliseconds sometimes its greater than a second, this happens in all environments from development to production.

Does anybody have some fresh things to try?

JustEngland
  • 1,371
  • 13
  • 30
  • It looks like we have a garbage collection problem. I am not quite sure of how to fix it exactly, but we are working on it. – JustEngland Mar 27 '12 at 14:41
  • JustEngland, We have a similar issue. Are you able to fix the DI performance issue? – Prasad Mar 28 '12 at 09:44
  • I am not sure that we are having a DI performance issue. But our DI implementation is suspect as it creates many extra objects. We have experimented with more our object life-cycle management. http://stackoverflow.com/questions/1151201/singleton-per-call-context-web-request-in-unity. Or real problem was garbage collection is filling up to fast. I suggest reading this blog http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector – JustEngland Mar 29 '12 at 13:40
  • About a year has gone by and we still battle with the garbage collector, other than network calls the garbage collector is huge problem on our website. I have found that telerik's just code really helps us tune our garbage collector. – JustEngland Jul 05 '13 at 20:54

2 Answers2

0

Check out MvcMiniProfiler.

It will allow you to measure the time it takes to render any portion of the action method you specify.

Not sure what you mean by "time it takes to start the action method".

Maybe there is some rogue action filters going on?

RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • It is takes up to second from begin request event until the controllers action method is fired. We are not noticing any spikes in memory, CPU or IO. – JustEngland Mar 26 '12 at 02:08
  • I am trying to figure out what else is happening before the controller is fired. – JustEngland Mar 26 '12 at 02:17
  • unless you have something crazy with your DI container going on, it should be HTTP request -> routing -> controller. is "up to a second" that bad? what are you expecting? – RPM1984 Mar 26 '12 at 02:45
  • This is a commercial website, I need it to be much faster than a second. When looking at StackOverflow, there site consistently has a time to first byte of about 1/2 a second, that is what I am looking for. – JustEngland Mar 26 '12 at 14:27
  • 1
    @JustEngland - SO doesn't use a DI Container ;) Perhaps you should look at running a faster one, several benchmarks rate AutoFac as very fast. StructureMap usually comes in second. – Travis J Mar 26 '12 at 19:39
  • @JustEngland - start with a new app, put in code bit by bit to see where the bottleneck is. – RPM1984 Mar 26 '12 at 23:03
  • @JustEngland Were you ever able to figure out what was causing the performance issues? I am dealing with the same thing and it's driving me crazy. – Todd Dec 11 '18 at 04:39
  • @Todd, Yes, we were able to manage our garbage collection issues, although they are always painful. Sam Saffron does a great job of giving the details. https://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector I found the best options were to keep the working memory small, in IIS. And periodically perform memory dumps and analyze what is in your garbage and remove it. For us, that meant switching from XML to JSON parsing and optimizing our parsing logic. – JustEngland Dec 21 '18 at 21:49
0

Sorry, but this is a large problem with having a huge singleton (unity) around implementing IDependencyResolver. I would bet that you are leaking memory.

edit

In response to your comment:

The reason that memory leak or the DI Container struck me as the issue is because there should be really no time inbetween the controller firing up and an action firing up as they are very close to each other. A simple way to test if it is a memory leak is to let the application sit unentered for a good amount of time (30 minutes to 2 hours) and then attempt to revisit it. If this is quick at first then that could indicate a memory leak. If it is slow on first request then perhaps it is something else. If memory leaking is not the issue then perhaps it is something easier. You said it is before the controller finishes so I would rule out rendering the view (which can take some time). Something you said makes me wonder about your web.config file. "this happens in all environments from development to production." Perhaps your production environment is still running under debug=true. These are all the ideas I could think of at the moment.

Travis J
  • 81,153
  • 41
  • 202
  • 273
  • we are not experiencing memory spikes of any kind – JustEngland Mar 26 '12 at 02:18
  • @JustEngland - It wouldn't necessarily be a memory spike as much as a retention of assets, perhaps a connection. But if you say it is not a memory issue I believe you. See my edit for some other thoughts. – Travis J Mar 26 '12 at 07:28
  • We have been running with good monitoring, and memory does not seem to be a problem. If there is another way to prove there is not a memory leak I am all ears. The web.config is set to debug=false, in production. – JustEngland Mar 26 '12 at 14:31
  • Ran across this and not sure you are still having the problem... However if you are, I am curious as to how you know it is your code and not an environment problem? I have had some bad experiences with asp.net mvc sites on some hosting services - particularly shared hosting services like godaddy. If that is the case, know that shared hosting services will typically recycle the app. pool every 20 minutes or so and your response time will suffer on subsequent loads. Have you experienced this issue in a local test environment? – jle May 19 '12 at 11:47