Taking up to 8.5 seconds to load blog post when 500+ blogs are in the system
My company is running Umbraco 4.7 on the Microsoft Azure Cloud and while the rest of the site runs fairly quickly, uBlogsy runs VERY slow with 500+ blogs imported into it. With only 50 or so blog posts imported in, ran great.
We have spent a ton of time analyzing all aspects of the site and deployment and have verififed that the number of blogs in the system is indeed the problem. We also experimented with taking individual macros off the right-side column and enabled caching but that only helps marginally on posts that have been clicked on before. New posts would still cause a 8+ second load time when they are first viewed.
Please advise as we love the fact that it uses Razor vs XSLT but we are about to have to go back to Blog4Umbraco because of the speed issue.
We took out all macros in the right-hand column except for the archives one. That plus taking out the next/prev code in the showpost.cshtml resulted in a blog post page load of around 4 seconds. That is roughly half the load time it was previously however that is with a loss of quite a bit of functionality and is still too slow.
Adding back in the categories and tags macros resulted in an additional 1.7 seconds of load time per blog post for a total of around 5.7 seconds even though none of the current blog posts have any tags nor categories assigned to them.
By the way, we are using the latest beta version of uBlogsy. There appears to be no speed difference between it and the latest full build. Also, we are using two large Azure instances, which is quite a bit more computing power and througput than most Umbraco setups that we have seen and read about.
On a side note, we had quite a few issues with the RSS import the worst of which being that some posts came in without dates and a few without titles causing Razor errors. In the case of not having titles, had to do quite a bit of tinkering to alleviate those. We can overcome those obstacles though, speed is the real issue.
Thanks again and we really hope you can figure out a solution soon. I imagine that everyone will encounter this same problem as time goes on and they have more and more blog posts.
Are you having this performance problem on localhost or on your dev environment? I have not heard of any issues with Azure.
Very curious that adding tags and cats back in causes more time. Are you sure it was not the related posts that was adding time? That seems more likely if you have no tags.
Regarding the rss import tool, can you post more details about the issue here:
This is on live, large instance Azure servers (plenty of performance) and a SQL Azure instance that we are currently testing on.
I'd imagine that in order to check to see if there are tags to display in the tag section, it still has to check all the posts in order to see if there are tags, regardless of whether there are any or not. However, we have not dwelved into that code so it may not work that way at all.
Yes, I am sure that it was not related posts.
At this point, I would have to guess that if we put in another 500 blog posts, the performace would degrade to twice the load time it is currently at. And that is without any macros being used beyond the comment, archive and blog roll.
To be more clear in response to your first question, the same performance issues occur in whatever environment we test them in. We have tried many new instances in Azzure in various sizes and on various localhosts.
Yes you're right about tags and iterating over nodes. I was thinking about tags and cats for the current post, not the other ones.
I just pissed off my gf for coding insteading spending time with her but here it goes...
I created 900 nodes on localhost, ublogsy 1.33. Running on IIS Express and sql CE. No browser cache, no cache for anything. No blogroll (this can cause latency due to external request).
Hitting a post takes no longer than 4sec for me.
Taking out the right column results in a 2 second load. This is the same effect as caching these macros.
Leaving the related posts macro makes it about the same. Related posts is quite intensive because it needs to check all tags across all nodes and should definitely be cached. But I didnt see an issue here.
Strange... It should all be significantly faster on a real sql server and real web server. Plus I assume that would be improved by caching the macros on the right column. Caching everything actually.
The only thing that stood out in terms of performace in the code was that I was returning a List<DynamicNode> where I could have returned IEnumerable<DynamicNode>. I made the change and saw a slight improvement but nothing drastic.
This is all very interesting. I Have you taken a look at the source? I would appreciate any insights you may have about what is causing this.
Lol, well thanks for that. Hope you didn't get in too much trouble.
4 seconds seems like quite a long time on your local machine. And the macros effectively doubling the page load time doesn't seem optimal either.
With all macros off with the exception of the archive and that being cached for 6 hours, we can achieve 3.5 second page loads (on average) for individual blog posts. That is with your default template. Now obvioulsy if you have already visited a blog post and it is cached, it will pull up within a second or so as expected.
Did the 900+ nodes that you created have any actual content in them? Were there any dates assigned to them? I would imagine that would make a difference. Ours are broken up into months and years over a 4 year period.
We will make the the IEnumerable change and see if that makes any difference.
I'm not really sure what else to tell you at this point. Our setup is more than adequate and we have done no customizations to your code other than what you suggested. We can't really set it up any better than it is right now. Any more help would be greatly appreciated.
FYI. Did another test and just adding in the categories macro by itself, cached, adds a full second to the page load.
Also, realized that we still had the top navigation macro in the blog. Took that out and resulted in another half second - to full second speed increase.
So from what I've been able to tell, each macro adds almost a second to the load time.
Thanks so much for the reply. Sorry for the delay on my response but have been out of cell phone reach white-water kayaking this weekend.
Do you happen to have the beta source you could post so we can make the recommended changes? That's the version we are currently using and don't see that the source is available.
I'm relatively new to Umbraco and uBlogsy (evaluating it for transferring a client from MT) but thought I'd try to help out.
Kevin - just do a Ctrl+Shift+F in Visual Studio 2010 and tell VS2010 to look in the macroScripts folder - you should see 8 occurances of the AncestorOrSelf code that Anthony mentions. You'd need the source in order to make the second change as I couldnt find GetPostSiblings in any of the cshtml files so assume it is in the dll.
As another thought - what about rewriting some of the slower pages in razor to access an Examine index that you setup (you can set one up in < 5 minutes using tutorials on here). Would also be interesting to see the perf difference between the two fo the page you are having issues with.
Matt - Thanks for the suggestions. We will look into the Examine index.
Anthony and Matt - The AncestorOrSelf code that you suggested changing does not appear to be in the beta version of uBlogsy, which is what we are using right now. All similar calls appear similar to the following:
There are big changes in 1.4 so you will have to remove ublogsy completely...but your content will be saved by packaging
There are a couple doc type name changes. You would have to package up your content, do a find an replace on the doctype names in the package xml before reinstalling your content.
Alternatively you can wait for 2.0beta which will have similar performance fixes. Shouldnt be too far off.
Taking up to 8.5 seconds to load blog post when 500+ blogs are in the system
My company is running Umbraco 4.7 on the Microsoft Azure Cloud and while the rest of the site runs fairly quickly, uBlogsy runs VERY slow with 500+ blogs imported into it. With only 50 or so blog posts imported in, ran great.
We have spent a ton of time analyzing all aspects of the site and deployment and have verififed that the number of blogs in the system is indeed the problem. We also experimented with taking individual macros off the right-side column and enabled caching but that only helps marginally on posts that have been clicked on before. New posts would still cause a 8+ second load time when they are first viewed.
Please advise as we love the fact that it uses Razor vs XSLT but we are about to have to go back to Blog4Umbraco because of the speed issue.
Thanks
Hi Kevin
Thanks for the performance report.
I suspect this could be one of the following:
- next/previous links
- related posts
I'm not able to look at this until the weekend but can you could do me a favour and test by removing those calls?
The next/prev code is in the showpost.cshtml, and the related post macro should be in the BaseSite.master
Have you taken a look at the source?
So this is just the individual post page where you have the performance issue? What about the landing page?
Thanks for the prompt reply.
We took out all macros in the right-hand column except for the archives one. That plus taking out the next/prev code in the showpost.cshtml resulted in a blog post page load of around 4 seconds. That is roughly half the load time it was previously however that is with a loss of quite a bit of functionality and is still too slow.
Adding back in the categories and tags macros resulted in an additional 1.7 seconds of load time per blog post for a total of around 5.7 seconds even though none of the current blog posts have any tags nor categories assigned to them.
By the way, we are using the latest beta version of uBlogsy. There appears to be no speed difference between it and the latest full build. Also, we are using two large Azure instances, which is quite a bit more computing power and througput than most Umbraco setups that we have seen and read about.
On a side note, we had quite a few issues with the RSS import the worst of which being that some posts came in without dates and a few without titles causing Razor errors. In the case of not having titles, had to do quite a bit of tinkering to alleviate those. We can overcome those obstacles though, speed is the real issue.
Thanks again and we really hope you can figure out a solution soon. I imagine that everyone will encounter this same problem as time goes on and they have more and more blog posts.
dammit...my last post didnt get saved.
Are you having this performance problem on localhost or on your dev environment? I have not heard of any issues with Azure.
Very curious that adding tags and cats back in causes more time. Are you sure it was not the related posts that was adding time? That seems more likely if you have no tags.
Regarding the rss import tool, can you post more details about the issue here:
http://our.umbraco.org/projects/starter-kits/ublogsy/ublogsy-bugs
This is on live, large instance Azure servers (plenty of performance) and a SQL Azure instance that we are currently testing on.
I'd imagine that in order to check to see if there are tags to display in the tag section, it still has to check all the posts in order to see if there are tags, regardless of whether there are any or not. However, we have not dwelved into that code so it may not work that way at all.
Yes, I am sure that it was not related posts.
At this point, I would have to guess that if we put in another 500 blog posts, the performace would degrade to twice the load time it is currently at. And that is without any macros being used beyond the comment, archive and blog roll.
To be more clear in response to your first question, the same performance issues occur in whatever environment we test them in. We have tried many new instances in Azzure in various sizes and on various localhosts.
Yes you're right about tags and iterating over nodes. I was thinking about tags and cats for the current post, not the other ones.
I just pissed off my gf for coding insteading spending time with her but here it goes...
I created 900 nodes on localhost, ublogsy 1.33. Running on IIS Express and sql CE. No browser cache, no cache for anything. No blogroll (this can cause latency due to external request).
Hitting a post takes no longer than 4sec for me.
Taking out the right column results in a 2 second load. This is the same effect as caching these macros.
Leaving the related posts macro makes it about the same. Related posts is quite intensive because it needs to check all tags across all nodes and should definitely be cached. But I didnt see an issue here.
Strange... It should all be significantly faster on a real sql server and real web server. Plus I assume that would be improved by caching the macros on the right column. Caching everything actually.
The only thing that stood out in terms of performace in the code was that I was returning a List<DynamicNode> where I could have returned IEnumerable<DynamicNode>. I made the change and saw a slight improvement but nothing drastic.
This is all very interesting. I Have you taken a look at the source? I would appreciate any insights you may have about what is causing this.
This article has some performance tweaks with umbraco. http://www.shrinkrays.net/articles/umbraco-hacks.aspx
Lol, well thanks for that. Hope you didn't get in too much trouble.
4 seconds seems like quite a long time on your local machine. And the macros effectively doubling the page load time doesn't seem optimal either.
With all macros off with the exception of the archive and that being cached for 6 hours, we can achieve 3.5 second page loads (on average) for individual blog posts. That is with your default template. Now obvioulsy if you have already visited a blog post and it is cached, it will pull up within a second or so as expected.
Did the 900+ nodes that you created have any actual content in them? Were there any dates assigned to them? I would imagine that would make a difference. Ours are broken up into months and years over a 4 year period.
We will make the the IEnumerable change and see if that makes any difference.
I'm not really sure what else to tell you at this point. Our setup is more than adequate and we have done no customizations to your code other than what you suggested. We can't really set it up any better than it is right now. Any more help would be greatly appreciated.
Thanks again!
FYI. Did another test and just adding in the categories macro by itself, cached, adds a full second to the page load.
Also, realized that we still had the top navigation macro in the blog. Took that out and resulted in another half second - to full second speed increase.
So from what I've been able to tell, each macro adds almost a second to the load time.
Hey Kevin
Thanks to Tim from the Cogworks I've managed to find 2 significant improvements.
Firstly, anywhere you see Model.AncestorOrSelf(1).DescendantsOrSelf("uBlogsyLanding") should be Model.AncestorOrSelf("uBlogsyLanding")
Secondly, this method:
private static List<DynamicNode> GetPostSiblings(DynamicNode current) { return current.AncestorOrSelf("uBlogsyFolderBlog") .Descendants("uBlogsyPost") .Items .Where(x => x.GetProperty("umbracoNaviHide").Value != "1" || x.Id == current.Id) .OrderByDescending(x => x.GetProperty("uBlogsyPostDate").Value) .ToList(); }We can drop the orderby and replace it with a reverse. Can also just return a IEnumerable.
Both of these halves the load time.
I'll be releasing a patch soon.
Thanks so much for the reply. Sorry for the delay on my response but have been out of cell phone reach white-water kayaking this weekend.
Do you happen to have the beta source you could post so we can make the recommended changes? That's the version we are currently using and don't see that the source is available.
Thanks
I'm relatively new to Umbraco and uBlogsy (evaluating it for transferring a client from MT) but thought I'd try to help out.
Kevin - just do a Ctrl+Shift+F in Visual Studio 2010 and tell VS2010 to look in the macroScripts folder - you should see 8 occurances of the AncestorOrSelf code that Anthony mentions. You'd need the source in order to make the second change as I couldnt find GetPostSiblings in any of the cshtml files so assume it is in the dll.
As another thought - what about rewriting some of the slower pages in razor to access an Examine index that you setup (you can set one up in < 5 minutes using tutorials on here). Would also be interesting to see the perf difference between the two fo the page you are having issues with.
Regards,
Matt
Matt - Thanks for the suggestions. We will look into the Examine index.
Anthony and Matt - The AncestorOrSelf code that you suggested changing does not appear to be in the beta version of uBlogsy, which is what we are using right now. All similar calls appear similar to the following:
Model.AncestorOrSelf("uBlogsyLanding").DescendantsOrSelf("uBlogsyRSS").First();
This appears to be the way you were suggesting doing it already, correct?
Thanks
Hey Kevin
Sorry for the late reply.
The performance improvements I've done will be available in a few weeks. Also, another major enhancement will be with caching descendentsOrSelf.
There is a bit of a performance issue with the Umbraco one which can be seen here on less than 2000 nodes:
https://twitter.com/#!/AnthonyDotNet/status/103029512060678144/photo/1/large
Matt I am considering using the examine index. I need to figure out how to handle multiple instances of uBlogsy in the same application though.
Ok.
1.34 is available with your performance issue taken care of (hopefully). Upgrade instructions on the ublogsy page.
ps. i've tested with about 2000 nodes. Page load is under 1sec :)
Sounds great but one quesiton. We are currently running 1.4. Anyway to downgrade or something to avoid loosing all the work we have currently done?
Thanks!
lol.
There are big changes in 1.4 so you will have to remove ublogsy completely...but your content will be saved by packaging
There are a couple doc type name changes. You would have to package up your content, do a find an replace on the doctype names in the package xml before reinstalling your content.
Alternatively you can wait for 2.0beta which will have similar performance fixes. Shouldnt be too far off.
Lol, we are a little hesitant to mess with uninstalling it given all the trouble we have had getting it working to begin with, especially with Azure.
I guess we will just pray that 2.0 beta comes soon. =)
is working on a reply...