我使用过asp.net配置文件(使用AspNetSqlProfileProvider)来保存有关用户的少量信息。我开始怀疑它如何处理大量用户的可靠配置文件。有没有人有在拥有大量同时用户的大型网站上使用此功能的经验？对性能有何影响？维护怎么样？

解决方案

我发现通过SQL来解决这个问题有些棘手，但是我已经与将其扩展到几百个属性的客户端一起工作，并且毫不费力地为10K +用户提供了帮助。授予的用户数量不多，但是到目前为止，它一直在起作用。

我认为这实际上取决于特定的项目，以及处理配置文件信息时确切需求。我们是否需要通过SQL定期查询？我们是否仅需要用户显示，这些类型的事情可能有助于为需求提供更可靠的答案。

SQL提供程序的性能与大量的铁产量紧密相关。性能或者多或者少与单个SQL Server处理查询数量的能力成正比。放大是唯一的选择，因此开箱即用时，它并不是真正的五分之一。

我们必须确定是否需要横向扩展性能和可用性，例如通过分区，复制，冗余等，并以何种性能代价。某些功能是可能的，因为当前的实现方式更多地针对中间市场和企业。

好事情是，我们可以将自己的个人档案提供程序的实现放到上面，然后将其添加到具有上述功能的服务和系统上。

我们编写了一个自定义的authn，authz和配置文件提供程序，并将其绑定到跨3个数据中心的大型AD / LDS LDAP群集。我们位于Comscore前10名中，因此我们可以说我们每天都在处理大量互联网。每秒1000个概要文件查询和100亿个概要文件可以通过良好的计划，工程和操作进行扩展。