I have an instance of Umbraco 4.7.0 with 76,000 members. Everything works except that it's extremely slow. I know this is a lot of members, but is there any way to increase performance? It's even affecting my /base calls and making them almost unresponsive. Has anyone else had any experiences with using Umbraco with this many members?
I have 1 member group and 1 member type. There are only 2 properties on the member type. Everything is slow, but that's probably because a lot of my calls involve associating a member with content.
Thanks for that link. I'm not a SQL guru in any way so I'll have to tinker around and see if I am able to figure anything out. At the very least this seems promising though. Thanks again! I was hoping there might be a SQL script in there for updating the database, but it looks like I'll have to figure it out, haha. :)
So, I added an index to the database and it seems to helped quite a bit. I haven't tested it thouroughly but, so far it's working quite nicely. Here's the SQL for the index:
CREATE INDEX Idx_cmsMember_LoginName ON cmsMember ("LoginName" ASC)
Do you use stuff like "GetAllMembersInRole"? To get members from one group? Are these types of querys slow? When you where talking about he perfomance, where you talking the acutal site or just interacting with the member API? Do you have any numbers about the difference in performence when adding that index? Like secounds or millisecounds?
What version of Umbraco is this? I think you can gain some performance by using either Examine or the uQuery (uComponents.Core.uQueryExtensions) (uComponents package (which is included in Umbraco as of 4.9 I think)) method uQuery.GetMembersByXPath(string xpath) which is also really fast.
Had a site with around 10k members and switching to the uQuery.GetMembersByXPath(string xpath) method instead of using the built-in methods and properties on the Member object made it run very smooth :-)
Sorry I didn't get back to this thread in a timely fashion. Things have been a bit busy over here, haha. I actually remedied it by using an alternate membership class (n3oMembership) that I found here:
I haven't updated the old site I was having issues with to a newer version of Umbraco since then and it's still running smoothly. I may have to do some extra testing with the newer version of Umbraco. If I remember correctly, the site I had built had around 76,000 members, and the performance problems were occuring when interacting with the member API. All of the members were of the same role so I couldn't use filtering such as "GetAllMembersInRole" as Markus mentioned. Unfortunately I don't have any numbers at hand as far as the performance increase when adding the index and switching to the n30Membership class, but it was definitely substantial as I would have many timeouts before made the switch.
That's good to hear about the uQuery stuff, I'll have to check it out and see if it makes a difference. :)
Umbraco is slow after creating lots of members
I have an instance of Umbraco 4.7.0 with 76,000 members. Everything works except that it's extremely slow. I know this is a lot of members, but is there any way to increase performance? It's even affecting my /base calls and making them almost unresponsive. Has anyone else had any experiences with using Umbraco with this many members?
Thanks,
Michael Lawrence
Hi Michael
Just a thought...
How many member groups do you have ?
How many properties do you have on your member types ?
Is the entire site slow, or just the members area ?
The additional info might assist in determining the issue.
Cheers
Nigel
Hi Nigel,
I have 1 member group and 1 member type. There are only 2 properties on the member type. Everything is slow, but that's probably because a lot of my calls involve associating a member with content.
Hi Michael,
I've read that including some indexes on the DB can improve performance relating to members. Check out this thread:
http://our.umbraco.org/forum/developers/api-questions/3117-Umbraco-Membership-Provider-for-large-ammounts-of-users
If you make any improvements please post your findings! FYI SQL Profiler is a handy tool for performance analysis.
CHeers
Barry
Hey Barry,
Thanks for that link. I'm not a SQL guru in any way so I'll have to tinker around and see if I am able to figure anything out. At the very least this seems promising though. Thanks again! I was hoping there might be a SQL script in there for updating the database, but it looks like I'll have to figure it out, haha. :)
So, I added an index to the database and it seems to helped quite a bit. I haven't tested it thouroughly but, so far it's working quite nicely. Here's the SQL for the index:
Hi Michael!
Do you use stuff like "GetAllMembersInRole"? To get members from one group? Are these types of querys slow? When you where talking about he perfomance, where you talking the acutal site or just interacting with the member API? Do you have any numbers about the difference in performence when adding that index? Like secounds or millisecounds?
Hi Michael,
What version of Umbraco is this? I think you can gain some performance by using either Examine or the uQuery (uComponents.Core.uQueryExtensions) (uComponents package (which is included in Umbraco as of 4.9 I think)) method uQuery.GetMembersByXPath(string xpath) which is also really fast.
Had a site with around 10k members and switching to the uQuery.GetMembersByXPath(string xpath) method instead of using the built-in methods and properties on the Member object made it run very smooth :-)
All the best,
Bo
Hey Markus and Bo,
Sorry I didn't get back to this thread in a timely fashion. Things have been a bit busy over here, haha. I actually remedied it by using an alternate membership class (n3oMembership) that I found here:
http://www.blogfodder.co.uk/2012/7/19/dealing-with-1000%E2%80%99s-of-members-in-umbraco-without-the-api-or-examine
I haven't updated the old site I was having issues with to a newer version of Umbraco since then and it's still running smoothly. I may have to do some extra testing with the newer version of Umbraco. If I remember correctly, the site I had built had around 76,000 members, and the performance problems were occuring when interacting with the member API. All of the members were of the same role so I couldn't use filtering such as "GetAllMembersInRole" as Markus mentioned. Unfortunately I don't have any numbers at hand as far as the performance increase when adding the index and switching to the n30Membership class, but it was definitely substantial as I would have many timeouts before made the switch.
That's good to hear about the uQuery stuff, I'll have to check it out and see if it makes a difference. :)
is working on a reply...