views:

175

answers:

2

I've got an upcoming project that is going to be dealing with 70,000+ users (education). I was wondering if the ASP.NET SqlMembership Provider has been used at such large capacities? Assuming the hardware is there, is there anything special that needs to be done to make it work smoothly? We're doing all the obvious things like separating boxes for databases and applications, but is there anything code wise that I need to watch out for?

+1  A: 

Inbuilt SqlMembershipProvider is very reliable and workable. They tightly integrate with FormsAuthentication and Login Controls. So authentication is reliable and it is also quick to implement.

Only problem I see is the complexity of the Database table structure, they are quite tidy and not so straight at first. So you can basically write your own MembershipProvider that will talk to your own users table with more simplistic design and implementation. Also Managing Members on admin is also painful due to table design but in a way it is fairly possible to do so. For these reasons we wrote our own MembershipProvider based on Sql. It's working amazingly and we've had good experience of the same.

If you have a small website or project you can straight go on with inbuilt SqlMembershipProvider but for a large project like yours I'd recommend writing your own MembershipProvider.

this. __curious_geek
+2  A: 

I know one site that, owner of this site wrote a brilliant article about asp.net performance(http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx)

On this article there is one subject that author describes a patch about profile provider for higher performance. Please read that section.

Efe Kaptan