We are doing standard performance testing of our Umbraco-based web site and have noticed that Umbraco responds very slowly to "bad" URLs (i.e., "404's"). The scenario where we have seen this occur is when we create an automated load test that attempts to access invalid URLs on our umbraco domain without the end user logging in. When approaching 30 or more simultaneous users we see performance slow down enough to cause our load balancer to kick in and deliver a "site not available" page. This could conceivably cause a "denial of service" scenario if left untreated.
What are our options for attempting to improve the response time for bad/invalid URLs? We've already tried editing umbracoSettings.config to redirect the user back to a specific page (the home page) if they enter in an invalid URL (i.e., a "404"), however that configuration fails with slow performance as well. Do we have to hook into the HTTP pipeline processing code to try and resolve this?
Would very much appreciate any insight or guidance with this...thanks!
Did you ever try this on a clean installation of Umbraco? In case it's the same result you might file an issue on http://issues.umbraco.org/dashboard then it will be picked up by the core team.
Okay, I'm trying to test the performance of a "vanilla" Umbraco installation. When doing the initial configuration on the step-by-step wizard I went ahead and chose the "simple" starter package. I was initially going to test out the URL query parameter "?umbDebug=true". However, using that does not get me any debug info (I don't see the little tab on the left that I can click to get the timing info for key processes). I've already verified that I have the setting
<addkey="umbracoDebugMode"value="true" />
in my web.config. What else am I missing? I also had a colleague test his own vanilla installation and he gets the same thing (no debug info).
Since our performance issue occurs with 404's, I am wondering if "ContentFinderByNotFoundHandlers" is in play during the slow-down? I don't believe we have much of a performance issue retrieving pages by ID or name, so switching out the order of number 2 with number 3 above did not seem to affect performance that much. We do have a large amount of Property Data. If it helps, below is a row count of each Umbraco Table sorted in descending order.
Alright, best to check with the mini profiler then what the holdup is and take it from there. Also, taking out the content finders one by one could give you a quick feel of where to start investigating.
We have run MiniProfiler and it shows 2 seconds in FindPublishedContent. Do you know how to get any more granularity to see what method(s) within FindPublishedContent are consuming the most time?
As you can see in the above, we've tried building a stock Umbraco 6.1.6 instance from the source in github and MiniProfiler will not function.
In the ApplicationStarting event handler I went ahead and removed the "ContentFinderByNotFoundHandlers" handler and that removed the performance delay on my local workstation. However, my question back to the forum is what impact will that have on our Umbraco-based application? We currently have the application configured to redirect the user back to the home page if they type in a bad URL (at least for now we do - may change that to a custom page down the road). However, other than http 404 scenarios, where else is this handler used? Are we losing out on critical functionality by not having it included in the list of ContentFinderResolvers?
Incidentally, here is the code segment we used in our even handler class:
Slow Performance with HTTP 404 Error
We are doing standard performance testing of our Umbraco-based web site and have noticed that Umbraco responds very slowly to "bad" URLs (i.e., "404's"). The scenario where we have seen this occur is when we create an automated load test that attempts to access invalid URLs on our umbraco domain without the end user logging in. When approaching 30 or more simultaneous users we see performance slow down enough to cause our load balancer to kick in and deliver a "site not available" page. This could conceivably cause a "denial of service" scenario if left untreated.
What are our options for attempting to improve the response time for bad/invalid URLs? We've already tried editing umbracoSettings.config to redirect the user back to a specific page (the home page) if they enter in an invalid URL (i.e., a "404"), however that configuration fails with slow performance as well. Do we have to hook into the HTTP pipeline processing code to try and resolve this?
Would very much appreciate any insight or guidance with this...thanks!
Hi Steve,
I think you have to hook into the HTTP pipeline code, we did it before. I don't know better solution than custom code.
Thanks
Does anyone have an example of how to do this?
I'm Steve's colleague, by the way.
If we run MiniProfiler to some non-existant URL: http://servername/nowhere.aspx?umbdebug=true
It shows 2 seconds (!) being consumed in FindPublishedContent. MiniProfiler shows it running an SQL query, but that takes only 34.9ms.
So what else is FindPublishedContent doing that is so slow?
Hi,
Did you ever try this on a clean installation of Umbraco? In case it's the same result you might file an issue on http://issues.umbraco.org/dashboard then it will be picked up by the core team.
Best,
Richard
Okay, I'm trying to test the performance of a "vanilla" Umbraco installation. When doing the initial configuration on the step-by-step wizard I went ahead and chose the "simple" starter package. I was initially going to test out the URL query parameter "?umbDebug=true". However, using that does not get me any debug info (I don't see the little tab on the left that I can click to get the timing info for key processes). I've already verified that I have the setting
<addkey="umbracoDebugMode"value="true" />
in my web.config. What else am I missing? I also had a colleague test his own vanilla installation and he gets the same thing (no debug info).
Thanks,
-Steve
Hi Steve
Perhaps the solution in this post can help? http://our.umbraco.org/forum/core/general/48353-No-mini-profiler-in-616#comment174068
/Jan
Hi Jan,
Our team members are running IIS 7.5 locally on Windows 7 laptops. Damian's instructions were for IIS 6. I tried adding a Wildcard Script Map but that did not work. I posted a response on that same thread: http://our.umbraco.org/forum/core/general/48353-No-mini-profiler-in-616#comment179189
Thanks,
-Steve
Check out the solution offered in the issue comments here: http://issues.umbraco.org/issue/U4-2844
Hi Sebastiaan,
Thanks for directing us there. Unfortunately that little trick did not improve the performance. There appear to be 4 types of "resolvers" being used:
Since our performance issue occurs with 404's, I am wondering if "ContentFinderByNotFoundHandlers" is in play during the slow-down? I don't believe we have much of a performance issue retrieving pages by ID or name, so switching out the order of number 2 with number 3 above did not seem to affect performance that much. We do have a large amount of Property Data. If it helps, below is a row count of each Umbraco Table sorted in descending order.
Thanks,
-Steve
Alright, best to check with the mini profiler then what the holdup is and take it from there. Also, taking out the content finders one by one could give you a quick feel of where to start investigating.
Sebastiaan,
We have run MiniProfiler and it shows 2 seconds in FindPublishedContent. Do you know how to get any more granularity to see what method(s) within FindPublishedContent are consuming the most time?
As you can see in the above, we've tried building a stock Umbraco 6.1.6 instance from the source in github and MiniProfiler will not function.
David
In the ApplicationStarting event handler I went ahead and removed the "ContentFinderByNotFoundHandlers" handler and that removed the performance delay on my local workstation. However, my question back to the forum is what impact will that have on our Umbraco-based application? We currently have the application configured to redirect the user back to the home page if they type in a bad URL (at least for now we do - may change that to a custom page down the road). However, other than http 404 scenarios, where else is this handler used? Are we losing out on critical functionality by not having it included in the list of ContentFinderResolvers?
Incidentally, here is the code segment we used in our even handler class:
ProtectedOverridesSub ApplicationStarting(app AsUmbracoApplicationBase, ctx AsApplicationContext)
' Remove undesired resolvers - this one was causing exceedingly slow reponse to http 404's
ContentFinderResolver.Current.RemoveType(OfContentFinderByNotFoundHandlers)()
EndSub
Thanks again for everyone's responses - really appreciate the help!
-Steve
is working on a reply...