We have moved to GitHub Issues
Created by Stephan 04 Jan 2017, 06:58:31 Updated by Brian Powell 23 Jan 2017, 19:38:32Tags: Unscheduled
Relates to: U4-9430
Relates to: U4-9121
Whenever the NiceUrl routing creates a url it double-checks whether that url can collide with another node. For every node. And that is killing the CPU on republish of large branches. But really, only the top-level nodes should be impacted? Investigate.
In this screenshot you can see the CPU perf profiling of what methods are chewing through the CPU. This sample is taking during a rename of a parent node that has 10,000+ children (in a list view) and the CPU due to the 301 tracker is killing perf.
the first part is during the initial event, the 2nd is during the final event.
I've noticed that we have perf/allocation issues with our config section which is not good. I've fixed this in this PR too but only for one section, we need to fix it for all sections.
NOTE: Need to change the XmlElement cast to an
as XmlElement and null check because it could be
I have taken care of that note
I have updated the PR with the following changes:
The fix is: we do ''not'' cache the url at all anymore when GetUrl(), only on inbound (when routing a request). BUT in the UI whenever we display a content, after we GetUrl(), we try to route that url to see if it reaches the content, or another one.
UI-wise the result is the same. Perfs-wise the result is the same in the UI (one routing per url). The good thing is that this routing takes place only in the UI and not all the time.
The semi-bad thing is that now if you render a page with 100 links, these will be fast to generate, but we won't cache the urls, meaning when a visitor tries any of these links we'll have to try to route the request (and cache the result). But I believe it's a minor hit (again once the page has been visited once the url is cached)
Regarding rendering a page with 100 links, does this mean that without caching that everytime this page renders it needs to recalculate all 100 links?
as long as none of these links have been visited, yes
so... I can see the problem, yes. had not thought about it. know how to fix, we need asymetric caching. will look into it today.
The good news is with the current changes, renaming a node that has thousands of children now only takes a few seconds, before it was minutes.
Have pushed a new commit, now the routes caching is asymmetric:
Assignee: Shannon Deminick
Backwards Compatible: True
Affected versions: 7.5.5, 7.5.6
Due in version: 7.5.7
Sprint: Sprint 50