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. :-)
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 ;)
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?
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 (?)
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.
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.
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
No? ;)
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
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
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 (?)
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.
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.
is working on a reply...