我正在开发一个预计会在短时间内吸引大量用户的网站，我们希望尽量减少服务器场所需的服务器数量。处理请求可能涉及本地I / O，对单个数据库服务器的SQL服务器请求以及对外部网站的http请求。我的第一个想法是我们肯定需要异步实现所有I / O，但在some more reading之后我不确定。
据我所知，对SQL Server的异步调用只会将瓶颈移到数据库服务器上。由于我们的数据库请求应该很快，因此最好保持它们同步，以便请求在多个Web服务器而不是单个数据库服务器之间排队。
为了访问本地文件系统，我怀疑同样的事情也可能是真的（只是将瓶颈进一步转移到操作系统中。）是否有充分的理由以异步方式执行本地文件I / O以读取/写入一个文件系统或者每个Web请求大小为25K-150K的两个文件？
访问外部网站是异步请求可能仍然有意义的一种情况。外部服务不太可能成为瓶颈（它比我们的站点需要的可扩展性更高），并且由于连接是通过Internet进行的，因此会引入更长的延迟（与db和本地文件相比）。这也应该是一种相对罕见的情况，可能是所有请求的5％。
我没有足够的经验对这些问题有一个良好的“直觉”，虽然我们需要做一些性能测试，但我们没有时间对所有可能的实现进行广泛测试。
它可能没什么区别，但本例中的软件堆栈是ASP.Net MVC 3和Sql Server。
为了了解范围，我们需要在两周内为大约1000万用户做好准备，可能是早期的峰值。该站点涉及上传和返回大约150K的文件，并在数据库中维护一些简单的记录。我们将它托管在CDN背后，但我关心的主要是文件和数据库I / O以及对外部网站的调用。
关于异步调用在这个应用程序中实际有用的地方的任何想法？
答案 0 :(得分：1)
如果你等了很长时间，异步会有所帮助。例如。您通过http或套接字向服务发起请求并等待15秒以进行响应。在这种情况下，阻塞线程进行等待是没有意义的，因为需要更多线程，这会花费上下文切换并花费大量内存。
在数据库异步的情况下，编写统计记录是有意义的，在这里您有火，忘记并且不等待响应。在任何其他情况下，我会分析为什么db太慢而你认为你需要异步。
通常我会说，异步的东西会大大增加复杂性，而且根据我的个人经验，它在很多情况下都不值得付出努力。在异步之前，我会使用缓存等优化其他地方。