Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Simon steed 376 posts 688 karma points
    Dec 07, 2012 @ 14:35
    Simon steed
    0

    Major performance issues with large Umbraco sites with Members

    Hi All

    Not sure how best to tackle this one but here goes. We've build a humongous site in Umbraco 4.9 for a client and are experiencing major performance issues.

    Site wise, the scope of the project is for around 220 clubs websites around the UK. We currently have around 80 domains in the one install of Umbraco all with centralised management for members. 

    Some numbers on the tables we have at the moment to give you an idea of size:

    • cmsContentCount = 45572 rows
    • cmsContentXmlCount = 36960 rows
    • cmsContentTypeCount = 107 rows
    • cmsDocumentCount = 87472 rows
    • cmsDocumentTypeCount = 625 rows
    • cmsMemberCount = 1997 rows
    • cmsMemberTypeCount = 108 rows
    • cmsMember2MemberGroupCount = 1443 rows
    • cmsPreviewXmlCount = 15537 rows
    • cmsPropertyDataCount = 2201702 rows
    • cmsPropertyTypeCount = 517 rows
    • cmsStylesheetCount = 52 rows
    • umbracoDomainsCount = 83 rows
    • Umbraco.config file is around 79meg

    The following is what we are experiencing:

    • Importing members - typically we are importing members from a spreadsheet for each club, can be anything from 400 - 1500 members, around 20 properties per member. CPU usage is averaging around 80% whilst this import is going on both with our custom import module and also similar with CMSImport. Network traffic to the DB is also massive, so much so that the server has actually crashed occasionally due to the high loads - is there a better way for us to be managing members in Umbraco i.e. split out the members tables completely and would this help performance?
    • Publishing is slow - there is one event handler in place but even if that is disabled, its still slow taking many seconds to publish one node. Multiple node publishing is painful and occasionally times out. When we do a full republish using http;//YOURDOMAIN/Umbraco/dialogs/republish.aspx?xml=true which we often need to do for some reason, if this process completes it can take in excess of 1hr 15 mins and obviously gets longer each time as more data is added to the sites.
    • CSS tree is very slow to initially load. Once a file is selected, large files are very hard to navigate around (Editor very slow and unresponsive)

    Server wise the infrastructure is run upon Amazon EC2 (managed by our client), IIS on one server, SQL Server on another box with fast links between the two.

    What we have done so far to help improve things:

    • Added indexes to some of the SQL tables - this has helped although there are still a lot of seeks and scans in the tables which should not be happening.
    • Removed properties from the document types and trying to extract more to other custom sections on the site i.e. members move out of the clubs homepage into a dedicated section
    • Refactored our code to the nth degree to ensure it's running as efficiently as possible
    • Modified core to support SQL Connection Timeout property

    I can reproduce a lot of the issues locally on my dev and staging environments but no where near to the same extent as on the live boxes (i.e. I rarely get SQL Timeouts for instance).

    Any ideas on what we can do to improve performance and how we can cope with the large amounts of data being bounded around here.

    Creating and updating members is particularly slow. If we create a member for instance, a hidden exception seems to be thrown but the member is still created! This will obviously be impacting performance. I've not yet debugged this but it's there and real!

    You won't find these issues in smaller sites but when you get to larger sites like in this instance, especially with many members on the system, Umbraco really does start to creak.

    From the investigations here, hopefully we can develop some best practices for improving the speed and performance of large Umbraco installations which of course will mean even faster smaller sites.

    Simon

  • Bo Damgaard Mortensen 719 posts 1207 karma points
    Dec 07, 2012 @ 15:04
    Bo Damgaard Mortensen
    0

    Hi Simon,

    There's a few things I'm curious about here:

    1. When working with members, do you use the built-ind methods and properties on the Member object from the Umbraco API?
    2. Are you using Razor or XSLT for outputting data?
    3. When working with the Umbraco API in general from C#: Are you using Node over Document whereever this is possible?
    4. Which version are you running? 

    All the best,

    Bo 

  • Simon steed 376 posts 688 karma points
    Dec 07, 2012 @ 15:08
    Simon steed
    0

    HI Bo

    To answer your questions:

    1. Using the older (yes I know deprecated) Umbraco methods, Tried upgrading to the new methods but lot of rework as not 100% backwards compatible
    2. XSLT for formatted Data
    3. Trying to use Node as much as possible, Document needs to be used it a lot of places as not published front end content i.e. settings etc
    4. 4.9 with slight mod to allow sql connection timeout property to be used in web.config
    Regards
    Simon
  • Bo Damgaard Mortensen 719 posts 1207 karma points
    Dec 07, 2012 @ 15:15
    Bo Damgaard Mortensen
    0

    Hi Simon,

    I think you could gain some good performance when performing reads on the members by using some of the Member extension methods from uComponents uQuery. What I'm using for getting members is the uQuery.GetMembersByXPath(string xpath) method. It's very fast :-) 

    Or your could move some read-logic to Examine for even faster performance.

    Bonus question: do you, by any chance, use a lot of extension methods (custom ones) in your XSLT?

    All the best,

    Bo

  • Simon steed 376 posts 688 karma points
    Dec 07, 2012 @ 16:04
    Simon steed
    1

    Hi

    Thanks, will look into those - for the member directory I wrote i'm actually using Lee Messengers uMember library which is faster but pulls back too much data - got a new query to optimise that.

    The members performance is mostly around importing data into Umbraco in the first place, that is where we are hitting major issues.

    There are a few extension methods but not overly used.

    Simon

  • Mads Krohn 211 posts 504 karma points c-trib
    Dec 07, 2012 @ 23:18
    Mads Krohn
    1

    Hey Simon

    A few years back, I came to the same conclusion you have come to now:
    The Umbraco Member API is painfully slow.

    Sadly, AFAIK, that's just how things are. If you want to get decent performance, you have to go another route. My suggestion would definitely be to look at using a custom table for members and member types and then import member data to these tables using either raw sql or a simple data access component like Simple.Data. I would then use DEWD to setup ways to query the members in any way you see fit; DEWD is really an awesome little tool for jobs like this.

    Again, publishing in Umbraco is slow. There is a lot of stuff going on at each publish and as you found out, it scales poorly. IIRC Umbraco has an upper limit of around 50k nodes before performance starts to take a serious hit. AFAIK, the reason why it starts to take so long is because of the xml cache being constantly updated, which is very slow when the physical Umbraco.config xml file gets large enough. Someone please correct me if I’m wrong.

    Unfortunately, I don’t think there’s anything to do about it at the moment. Work is being done on a new caching system for Umbraco which will drop the xml cache completely while still supporting xslt. If/when this cache is fully implemented the upper limit for nodes should increase at least tenfold while maintaining great performance. Of course, this doesn’t help you now, and it’s just to let you know, that the future of Umbraco is indeed shaping up to better handle large Umbraco installations.

    That’s all for me, hopefully you found some of it just a tad helpful :)

    Regards
    Mads

  • Bav Patel 4 posts 25 karma points
    Oct 03, 2013 @ 10:33
    Bav Patel
    0

    Using Lucene.Net, can a solution be built for this issue, as I've read it's very fast for parsing nodes? I've not used it myself, bu it could be worth considering.

    Is this issue just for the members section?

Please Sign in or register to post replies

Write your reply to:

Draft