Copied to clipboard

Flag this post as spam?

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


  • Bo Damgaard Mortensen 719 posts 1207 karma points
    May 03, 2011 @ 13:46
    Bo Damgaard Mortensen
    0

    Members and performance

    Hi all,

    I know this has been covered a few times before, but I never really found any solution/answer to this.

    I'm about to develop a site which is pretty much driven by the Member section. In this case, the amount of members is estimated to reach 10.000+ and each member will need to have 25+ properties (apart from loginname, password)

    My question is, will this cause performance problems? I plan to use the ASP.NET Membership API and not the regular, deprecated umbraco member api.

    Has anyone ever created a site with this great amount of members? If so, I would love to hear from you, how you handled the amount of members performancewise. :-)

    Any help is greatly appreciated!

    All the best,

    Bo

  • Bo Damgaard Mortensen 719 posts 1207 karma points
    May 05, 2011 @ 13:58
    Bo Damgaard Mortensen
    0

    No? ;)

  • Morten Christensen 596 posts 2773 karma points admin hq c-trib
    May 08, 2011 @ 11:36
    Morten Christensen
    0

    Hi Bo,

    I haven't been in the 10.000+ member range yet, but am currently developing a site that starts out with 1.000+ members. We are also using ASP.NET membership API (but) with the umbraco implementation, so the editors can associate members with certain pages on the website from the member section. So far its been working well, but we have also had performance concerns from the start. That is why we chose to use Examines member implementation for doing various actions that require looking through the members.
    This basically means that all members along with properties are indexed when created and updated, so we can do fast lookups and iterations using the index which is super fast! The only "issue" with using examine is that properties won't be updated instantly, because you save the properties which are then indexed. But this has been fairly easy to get around.

    I think your biggest concern would have to be performance in the member section in Umbraco, i.e. expanding the A-folder and loading the x number of members in a single folder - and not so much on the website itself.

    Probably doesn't answer your question, but hope its usable input ;)

    - Morten

  • Bo Damgaard Mortensen 719 posts 1207 karma points
    May 08, 2011 @ 13:13
    Bo Damgaard Mortensen
    0

    Aww, for some reason my post didn't get saved in Chrome :/ Ah well.

    Thanks Morten, that's just what I wanted to know :-)

    So basically you just use the built-in Member Examine index (the search field in the members section) for finding members, right?

    I went and grabbed the bull by it's horns and created 10.211 Members (yes, I did use a loop for this ;)) and the backend still seems to be running pretty smooth. Takes about 1 - 2 seconds to expand a letter-node. The "Other" node takes a bit longer, maybe ~3 seconds as it contains more nodes than any of the letter nodes because I used a GetUniqueKey() method when creating the members.

    The only thing I'm concerned about now is, that the 10k members I created don't have any properties on them except for the regular Username, Password and Email. Will adding more properties to a member cause more overhead in the backend?

    Thanks again! :-)

    - Bo

  • Bo Damgaard Mortensen 719 posts 1207 karma points
    May 08, 2011 @ 13:24
    Bo Damgaard Mortensen
    0

    Another thing I noticed was that when I switched to the Members section and then to any of the other sections, the whole backend tends to freeze for up to ~4 seconds. But I guess there's nothing to do about that (?)

  • Simon Dingley 1474 posts 3431 karma points c-trib
    May 09, 2011 @ 09:48
    Simon Dingley
    0

    A couple of years ago in a project I was working on with Lee Kelleher we had around 4000 members on launch, this has obviously increased since then but still running fine v 4.0.3. The solution works pretty much the same as that described by Morten, it indexed member properties in Lucene for faster searching and to this day it works well however the one issue that is still apparent is the time it takes to build the index which is sometimes in excess of 1 hour on 64-Bit Win2K8 with 3GB RAM and a 2.5Ghz processor! There are however approximately 50 properties on each member which I expect is the biggest contributor to the time it takes to build the index.

    If the client gives me the chance to upgrade the site I would take the opportunity to update the solution to use Examine.

    One other thing that has been mentioned is the time it takes to expand the directories in the member section. I have simply replaced with a search feature but you could just prevent the child nodes from loading and display them as paged list when clicking on a directory. I don't find this area particularly useful anyway as members are organised by forename rather than surname in the members (and Users) sections.

  • skiltz 501 posts 701 karma points
    May 09, 2011 @ 10:44
    skiltz
    0

    You can roll your own Memership provider.  We have a site with over 40,000 members and this works just fine.  Just inherit from UmbracoMembershipProvider and UmbracoRoleProvider and override the appropriate functions.   If I had a lot of members and properties I would stay well clear of any builtin membership functionality. 

Please Sign in or register to post replies

Write your reply to:

Draft