在 Web 服务器上，什么时候值得进行异步 I/O？
我正在开发一个网站，预计会在短时间内吸引大量用户，并且我们希望最大限度地减少服务器场所需的服务器数量。处理请求可能涉及本地 I/O、对单个数据库服务器的 sql server 请求以及对外部网站的 http 请求。我的第一个想法是我们肯定需要异步实现所有 I/O，但是在 更多阅读 我不太确定。
据我所知，对 SQL 服务器的异步调用可以简单地将瓶颈转移到数据库服务器。由于我们的数据库请求无论如何都应该很快，因此最好保持它们同步，以便请求在多个 Web 服务器而不是单个数据库服务器上排队。
对于访问本地文件系统，我怀疑同样的情况也可能成立（只是将瓶颈进一步移至操作系统中。）是否有充分的理由异步执行本地文件 I/O 来读取/写入一两个文件每个 Web 请求的大小为 25K-150K？
访问外部网站是异步请求可能仍然有意义的一种情况。外部服务不太可能成为瓶颈（它的可扩展性比我们的站点所需的要高得多），并且会引入更长的延迟（与数据库和本地文件相比），因为连接是通过互联网进行的。这应该也是一种相对罕见的情况，可能占所有请求的 5%。
我没有足够的经验来对这些问题有良好的“直觉”，虽然我们需要进行一些性能测试，但我们没有时间广泛测试所有可能的实现。
它可能没有什么区别，但本例中的软件堆栈是 ASP.Net MVC 3 和 Sql Server。
为了了解范围，我们需要在两周内为大约 1000 万用户做好准备，可能会出现早期峰值。该站点涉及上传和返回大约 150K 的文件，并在数据库中维护一些简单的记录。我们将其托管在 CDN 后面，但我主要关心的是文件和数据库 I/O，以及对外部网站的调用。
对于异步调用在此应用程序中实际有何帮助有何想法？
I'm working on a web site that is expected attract a large number of users within a short time, and we want to minimize the number of servers required on the farm. Handling requests can involve local I/O, sql server requests to a single db server, and http requests to an external website. My first thought was that we definitely need to implement all I/O asynchronously, but after some more reading I'm not as certain.
I understand that asynchronous calls to a sql server can simply move the bottleneck to the db server. Since our db requests should be fast anyway, it might be better to keep them synchronous so that requests queue up across multiple web servers instead of the single db server.
For accessing the local file system, I suspect the same thing might also be true (just moving the bottleneck further down into the OS.) Would there be a good reason to do local file I/O asynchronously for reading/writing one or two files that are 25K-150K in size per web request?
Accessing external websites is the one case where asynchronous requests might still make sense. The external service is not likely to become a bottleneck (it is much more scalable than our site needs to be), and will introduce longer delays (compared to db and local files) since the connection is across the Internet. This should also be a relatively rare situation, maybe 5 percent of all requests.
I don't have enough experience to have a good "gut feeling" on these issues, and while we will need to do some performance testing, we don't have time to extensively test all the possible implementations.
It probably doesn't make a difference, but the software stack in this case is ASP.Net MVC 3 and Sql Server.
For a sense of the scope, we need to be ready for around 10 million users over two weeks, probably with an early spike. The site involves uploading and returning files of around 150K, and maintaining some simple records in a db. We're hosting it behind a CDN, but my concern is mostly with the file and db I/O, and the calls to an external website.
Any thoughts on where asynchronous calls would actually help in this application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您等待很长时间，异步会有所帮助。例如，您通过 http 或套接字向服务发起请求，并等待 15 秒以获得响应。在这种情况下，阻塞线程等待是没有意义的，因为需要更多线程，这会消耗上下文切换并消耗大量内存。
在数据库的情况下，异步对于编写统计记录是有意义的，在这种情况下，您会一劳永逸，而不是等待响应。在任何其他情况下，我都会分析为什么数据库太慢以至于您认为需要异步。
通常我会说，异步的东西大大增加了复杂性，根据我个人的经验，在很多情况下这是不值得的。在异步之前，我会在其他地方进行优化，使用缓存等。
Async helps if you wait for a long time. E.g. you start a request via http or socket to a service and wait 15 seconds for response. In this case it makes no sense to block a thread for waiting as more threads are required which costs context switches and cost a lot of memory.
in the case of databases async makes sense for writing statistic records, where you have a fire and forget and dont wait for the response. In any other case i would analyze why the db is too slow that you think you require async.
normally i would say, async stuff heavily increases complexity, and in my personal experience it was in many cases not worth the effort. I would optimize everywhere else, using caching etc before going async.