Is there a limit or a point where performance starts to take a hit, with having too many member properties/values. I'm using the asp.net ProfileBase and currently have 32 properties, and it very well may turn into about 100+ by the time I'm done. So I wanted to just make sure that I woudln't run into issues down the road this way.
There is definitely a limit where you begin to run into problems. Many things in the Umbraco back-office will get really slow once you have a lot of properties - you want to keep a limit on them.
We did a website some time ago, that has 497 properties on one of the member types. I recall that there was a hard limit where Umbraco failed entirely but I don't recall exactly what that number was (not much higher than what we have, so probably 500?).
Mostly this isn't a major issue, but loading the member type or members of that type are slow operations. 100-150 properties would probably work but I would definitely think about storing things differently if you are going any higher. I wouldn't do the 497 above again if re-doing that site today.
Far more of a concern is that Members aren't cached in Umbraco the same way that documents are. So working with members with a lot of properties can get slow. Accessing members via Examine can be a solution to get at members quickly, but just bear in mind that doing "new Member(id)" on a Member isn't coming out of a cache so a lot of members with a lot properties is going to be a non-trivial activity. But that depends on what you're going to do with the data.
Note: this was on Umbraco 4.5.2 so hopefully things have improved. But this is the sort of thing I wouldn't expect to have been looked at much in the interleaving versions.
Member ProfileBase property Limit
Is there a limit or a point where performance starts to take a hit, with having too many member properties/values. I'm using the asp.net ProfileBase and currently have 32 properties, and it very well may turn into about 100+ by the time I'm done. So I wanted to just make sure that I woudln't run into issues down the road this way.
There is definitely a limit where you begin to run into problems. Many things in the Umbraco back-office will get really slow once you have a lot of properties - you want to keep a limit on them.
We did a website some time ago, that has 497 properties on one of the member types. I recall that there was a hard limit where Umbraco failed entirely but I don't recall exactly what that number was (not much higher than what we have, so probably 500?).
Mostly this isn't a major issue, but loading the member type or members of that type are slow operations. 100-150 properties would probably work but I would definitely think about storing things differently if you are going any higher. I wouldn't do the 497 above again if re-doing that site today.
Far more of a concern is that Members aren't cached in Umbraco the same way that documents are. So working with members with a lot of properties can get slow. Accessing members via Examine can be a solution to get at members quickly, but just bear in mind that doing "new Member(id)" on a Member isn't coming out of a cache so a lot of members with a lot properties is going to be a non-trivial activity. But that depends on what you're going to do with the data.
Note: this was on Umbraco 4.5.2 so hopefully things have improved. But this is the sort of thing I wouldn't expect to have been looked at much in the interleaving versions.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.