We have moved to GitHub Issues
Created by Sebastiaan Janssen 26 Oct 2016, 13:28:25 Updated by Stephan 04 Jan 2017, 07:05:00Tags: Unscheduled
Relates to: U4-9337
While analyzing a site that makes use of many calls to RenderMacro it became apparent that one of the bottle necks for perfomance on the frontend was that each call to GetRouteById is doing collision detection, taking up about 80% of the time it took to execute RenderMacro. After commenting out that part of the code, suddenly just 1.4% of the time to render the macro is spent in this method.
We do this collision detection so we can show a message in the backoffice when URLs get assigned the same route. This code should only run in the backoffice and not when rendering things on the frontend.
Before we "fixed" GetRouteById it would determine and cache a node's route regardless of whether ''another node'' had the same route, resulting in routing confusion, e.g. the route would be attributed to the first node being visited, giving the impression that Umbraco was randomly routing nodes.
So GetRouteById was "fixed" by reverse-testing the route and, if it pointed to a ''different'' node, report an error and not (pollute the) cache.
Routes are cached so this logic runs every first time a Url is retrieved for a node. Nevertheless, reverse-testing the routes has an impact. But, we cannot do it "in the backoffice only" as we would happily pollute the cache and go back to the random situation. And yet the reverse-testing is too expensive.
Now what? Need to think about it...
What it does: I have refactored how we navigate the Xml tree when handling urls, replacing XPath with pure C# navigation. The PR adds a new benchmark class that seems to indicate that this revisited navigation is about 16x faster.
My hope is that this improved navigation will make it possible to keep reverse-testing the routes, as I cannot see any "obvious" way to maintain routes sanity if we don't test them.
Test: tests should all pass, and creating/getting urls should still work, with or without domains. And... perfs are OK now?
@zpqrtbnk any idea what version of Umbraco this was released in??
Commit (from PR) c500f98ad8137b86e71b03b159089e3344ab8553
Follows: release-7.5.4 Precedes: release-7.5.5
So I'd say 7.5.5
Backwards Compatible: True
Due in version: 7.5.5
Sprint: Sprint 45