asp.net 配置文件系统有多强大？ 准备好迎接黄金时段了吗？
我使用 asp.net 配置文件（使用 AspNetSqlProfileProvider）来保存有关我的用户的少量信息。 我开始想知道它将如何处理大量用户的强大配置文件。 有人有在具有大量并发用户的大型网站上使用此功能的经验吗？ 对性能有何影响？ 保养怎么样？
I've used asp.net profiles (using the AspNetSqlProfileProvider) for holding small bits of information about my users. I started to wonder how it would handle a robust profile for a large number of users. Does anyone have experience using this on a large website with large numbers of simultaneous users? What are the performance implications? How about maintenance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现通过 SQL 运行它有点棘手，但我曾与客户合作过，这些客户已将其扩展到数百个属性和 10K+ 用户，毫无困难。 虽然用户不多，但到目前为止它正在运行。
我认为这实际上取决于具体的项目，以及您在使用个人资料信息时的具体需求。 您需要定期通过 SQL 查询吗？ 您是否只需要用于用户显示，这些类型的内容可能有助于为您的需求提供更可靠的答案。
Running against this via SQL I have found is a bit tricky, but i have worked with clients that have scaled it up to a few hundred properties, and 10K+ users without difficulty. Granted not a lot of users but it is working thus far.
I think it really depends on the specific project, and your exact needs when it comes to working with the profile information. Do you need to query on it regularly via SQL? Do you just need to for user display only, these types of things might help provide a more solid answer for your needs.
SQL 提供程序的性能与大铁吞吐量的相关性更为密切。 性能或多或少与单个 SQL Server 处理查询数量的能力成正比。 扩大规模是唯一的选择，因此它并不是真正的“五个九”。
您必须弄清楚是否需要横向扩展性能和可用性（例如通过分区、复制、冗余等）以及性能成本。 有些功能是可能的——当前的实施更多地针对中间市场和企业。
好处是您可以放置自己的配置文件提供程序的实现 - 然后将其附加到具有上述功能的服务和系统。
我们编写了一个自定义的 authn、authz 和配置文件提供程序，并将其绑定到跨 3 个数据中心的大型 AD/LDS LDAP 集群。 我们位列 Comscore 前 10 名 - 因此您可以说我们每天都在处理很大一部分互联网业务。 每秒 1000 个配置文件查询和 1 亿个配置文件 - 它可以通过良好的规划、工程和操作进行扩展。
The SQL provider performance is more closely correlated to big iron throughput. Performance is more or less directly proportional to a single SQL Server's ability to handle the number of queries. Scale-up is the only option, so as such its not really five-nines robust out the box.
You'll have to figure out if you need scale-out performance and availability e.g. through partitioning, replication, redundancy etc. and at what cost to performance. Some of the capabilities are are possible as is - the current implementation is more aimed at the middle-market and enterprise.
Good thing is you can put your own implementation of the profile provider - then attach it to services and systems with capabilities outlined above.
We wrote a custom authn,authz and profile provider and strapped it to large AD/LDS LDAP cluster across 3 datacenters. We're in the Comscore Top 10 - so you could say that we deal with a good slice of internet every day. 1000's of profile queries per second and 100'millions of profiles - it can scale with good planning, engineering and operations.