.NET Web 服务的可扩展性
谁能帮我解决有关网络服务和可扩展性的问题吗？我已经编写了一个 Web 服务作为文档管理系统的外观，并且需要考虑可扩展性问题。我应该关注哪些方面来确保性能和可用性？
提前致谢
Can anyone help me with a question about webservices and scalability? I have written a webservice as a facade into our document management system and need to think about scalability issues. What areas should I be looking at to ensure performance and availability?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
性能与可扩展性是分开的。可扩展性意味着您可以添加更多服务器来线性增加系统吞吐量（即更多客户端连接）。最好的开始方式是使用无状态 Web 服务。这样，任何客户端都可以调用 n 个不同机器上的 n 个 Web 服务实例中的任何一个。如果最后有一个用于持久性的共享数据库，那最终将成为您的瓶颈。有多种方法可以通过数据分区和分片来减少这种情况，但前提是您达到了这一点。
Performance is separate from scalability. Scalability means that you can add more servers to linearly increase system throughput (i.e more client connections). The best way to start is having stateless webservices. That way any client can call any of the n webservice intance on n different machines. If there is a shared database at the end for persistence that will ultimately be your bottleneck. There are ways to reduce that with data partitioning and sharding, but only when you get to that point.
首先，确定您的网络服务可接受的行为。它应该能够应对什么——每秒 1000 个连接？每个连接的响应时间是多少？
然后，您需要自动化 Web 服务的使用，以便可以对系统进行压力测试。
当每秒 100 个请求时会发生什么？ 1000？ 10000？
然后，您可以决定性能是否可以，可接受的行为是否太严格，或者是否需要根据实际分析数据进行大量性能调整。
First of all, decide what is acceptable behaviour of your web service. What should it be able to cope - 1000 connections per second? What response time will each connection have?
Then you need to automate the usage of your web service so you can stress test the system.
What happens when you have 100 requests per second? 1000? 10000?
Then you can make a decision about if performance is ok, if the acceptable behaviour is too strict, or if you need to do heavy performance tuning based on actual profiling data.
您应该希望在 IIS 中托管 WCF 服务。 IIS 具有许多内置的性能、可扩展性、安全性等机制，是避免您重新发明轮子的最佳起点。
You should be looking to host your WCF service in IIS. IIS has a lot of performance, scalability, security etc. mechanisms built in and is the best starting point to save you reinventing the wheel.
某些性能肯定是由于您自己的代码造成的，但我们假设它已经过优化。此时，额外的性能扩展问题涉及服务主机（例如 IIS）、托管它的计算机及其网络（内部/内部网）连接速度。您需要进行一些速度测试来确定情况。
Some of the performance is certainly due to your own code, but lets assume that it's already optimized. At that point, the additional performance scaling issues involve the service host (e.g. IIS) the machines that host it, and their network (inter/intranet) connection speeds. You'll need to do some speed tests to be sure of things.
嗯，这实际上取决于您在网络服务中所做的事情，但您要找出答案的唯一方法是模拟大量用户并对其进行测量。
看看我对这个问题的回答：测量性能
当我们在这个庄园（Web 服务托管在 Windows 服务中）测试我们的代码时，我们发现瓶颈在于对外观服务中的每个用户进行身份验证。特别是 Windows 组件 LSASS 使用了大部分 CPU。
幸运的是，我们能够创建新机器，每台机器都有一个外观服务，然后调用我们的主要 Web 服务集。这使我们能够扩展到大量用户（正常使用我们软件的用户约为 100,000 名）。
Well it really depends on what you're doing in your web service, but the only way you're going to find out is by simulating lots of users and measuring it.
Take a look at my answer to this question: Measuring performance
When we tested our code in this manor (where the web services were hosted in Windows service(s)), we found that the bottleneck was authenticating each user in the facade service. In particular the windows component LSASS was using most of the CPU.
Luckily we were able to create new machines, each with a facade service, which then called through to our main set of web services. This enable us to scale up to a large number of users (in the region of 100,000 users using our software normally).