Ok, the above RenderMacroContent() is the cause of the duplicated loadings. I have removed all references to that and that part of the problem went away.
Now the next performance issue:
aspx.page
Begin Load
10.8106410172243
0.000015
aspx.page
End Load
22.962396058717
12.151755 Seconds!
It is taking 12 seconds to render controls, ouch. This is proportional to the size of the Umbraco.config cache. Meaning if we get rid of content the page load time is greatly reduced. Anyone know if this is solely usercontrols slowing things down on Page_load?
And finally:
The 'resolve urls' times total 10 seconds by themselves. I saw somewhere that this can possibly be disabled. Looking into that as well.
One last comment, the trace has several lines that say 'Resolve Urls', these seem to correlate with the amount of time it took the macro to run. I focused on the macros that had high 'Resolve Urls' times.
Thanks for sharing all of this information with us. I'm sure this will come in handy for others as well. I think it's great that you update the post with the stuff you figure out along the way.
Currently we're seeing some similar issues on a site we're about to launch as well. I think many people get confused about the "ResolveUrls" stuff when viewing the trace log because it seems it is what is causing the issues where it is usually the macro rendering in most cases.
The weird thing about our site is that it is performing well on our test server, which is running around 10 other test sites as well and potentially has a higher amount of traffic than the coming live site has currently. But on the test-server the initial page load is about 8-15 seconds and some of the macroes takes about 2-3 seconds to load on the live environment.
In this case it seems it might be a firewall issue in the live setup - I'll be following up on this post once we figure out what is the cause of the issue with our site.
Ok, so the performance issues we're experiencing is a combination of an underdimensioned server and two xslt files that needs to be optimized. One of them is solved and cut the load time by about 2 seconds.
This is because we have som default settings on each of root nodes of these sites and there can be created multiple campaign and microsites, which can be structured in folders.
By refactoring the above to this simple variable below, we saved about 2 seconds!
<xsl:variable name="settings" select="$currentPage/ancestor-or-self::*[self::Home or self::Campaignsite or self::Microsite]" />
This is enought to make the site perform well. But we can make it perform even better once we've dealt with the other
Great job Jan. XSLT has been a learning experience. I recently switched over to .NET/Umbraco from the PHP/Drupal world and its been challenging/rewarding. Pleased to meet you.
Topic author was deleted
Performance Issues 4.7.2, Multiple Loading of Same Page Elements
We are having severe performance issues with one of our Umbraco 4.7.2 installs.
Our Umbraco.config file is ~18MB.
When we load a product page, the trace seems to indicate the macros are loading the page elements over and over.
We have other installs where the page elements only load once (seemingly correct).
For instance, the following trace, the page elements load 15-20 times per request.
I'd assume this is not normal and is the cause of our slowdown.
A typical page like this takes 20 seconds to render. With macro caching, it takes about 1 sec.
Can anyone give me any insight on what normally should be happening with page element loads?
Trace Information
Comment author was deleted
It appears to be related to this extension:
Still looking for other reasons as to why it is so slow.
Comment author was deleted
Ok, the above RenderMacroContent() is the cause of the duplicated loadings. I have removed all references to that and that part of the problem went away.
Now the next performance issue:
It is taking 12 seconds to render controls, ouch. This is proportional to the size of the Umbraco.config cache. Meaning if we get rid of content the page load time is greatly reduced. Anyone know if this is solely usercontrols slowing things down on Page_load?
And finally:
The 'resolve urls' times total 10 seconds by themselves. I saw somewhere that this can possibly be disabled. Looking into that as well.
Comment author was deleted
Ok so I updated umbracosettings.config to show:
<ResolveUrlsFromTextString>false</ResolveUrlsFromTextString> <--was set to true.
But still no improvement.
We are using macro caching, so the pages are still taking ~25 seconds to load (initial) and then about 1 second on the second request (cached).
Still looking for answers. Investigating why the cached content still takes 1 second (expecting 100ms or so).
Comment author was deleted
Apologies for the 'stream of consiciousness' type postings.
I can reduce the cached time by caching one of the slower (non-cached) macros.
Now if I can just get rid of the 25 second initial load, I'll be g2g.
Comment author was deleted
Zeroing in on the issue. Cut it half by optimizing an Excel User Control.
Comment author was deleted
Solved!
The issue was multi-threaded, but in the end the Umbraco traces pointed to the macros as being the place to look.
Observations\Lessons Learned:
Comment author was deleted
One last comment, the trace has several lines that say 'Resolve Urls', these seem to correlate with the amount of time it took the macro to run. I focused on the macros that had high 'Resolve Urls' times.
I love that you share your solution plus thoughts on solving along the way! Glad it worked out!
#h5yr!
Hi Kevin
Thanks for sharing all of this information with us. I'm sure this will come in handy for others as well. I think it's great that you update the post with the stuff you figure out along the way.
Currently we're seeing some similar issues on a site we're about to launch as well. I think many people get confused about the "ResolveUrls" stuff when viewing the trace log because it seems it is what is causing the issues where it is usually the macro rendering in most cases.
The weird thing about our site is that it is performing well on our test server, which is running around 10 other test sites as well and potentially has a higher amount of traffic than the coming live site has currently. But on the test-server the initial page load is about 8-15 seconds and some of the macroes takes about 2-3 seconds to load on the live environment.
In this case it seems it might be a firewall issue in the live setup - I'll be following up on this post once we figure out what is the cause of the issue with our site.
/Jan
Ok, so the performance issues we're experiencing is a combination of an underdimensioned server and two xslt files that needs to be optimized. One of them is solved and cut the load time by about 2 seconds.
In a global variable we had this mess
<xsl:variable name="main" select="$currentPage/ancestor-or-self::Home/@id" />
<xsl:variable name="campaign" select="$currentPage/ancestor-or-self::Campaignsite/@id" />
<xsl:variable name="microsite" select="$currentPage/ancestor-or-self::Microsite/@id" />
<xsl:variable name="settings">
<xsl:choose>
<xsl:when test="$currentPage/ancestor-or-self::Microsite">
<xsl:copy-of select="umbraco.library:GetXmlNodeById($microsite)"/>
xsl:when>
<xsl:when test="$currentPage/ancestor-or-self::Campaignsite">
<xsl:copy-of select="umbraco.library:GetXmlNodeById($campaign)"/>
xsl:when>
<xsl:when test="$currentPage/ancestor-or-self::Home">
<xsl:copy-of select="umbraco.library:GetXmlNodeById($main)"/>
xsl:when>
xsl:choose>
xsl:variable>
This is because we have som default settings on each of root nodes of these sites and there can be created multiple
campaign and microsites, which can be structured in folders.
By refactoring the above to this simple variable below, we saved about 2 seconds!
<xsl:variable name="settings" select="$currentPage/ancestor-or-self::*[self::Home or self::Campaignsite or self::Microsite]" />
This is enought to make the site perform well. But we can make it perform even better once we've dealt with the other
macro. Will post any usefull info in here.
/Jan
Comment author was deleted
Great job Jan. XSLT has been a learning experience. I recently switched over to .NET/Umbraco from the PHP/Drupal world and its been challenging/rewarding. Pleased to meet you.
is working on a reply...