IIS性能“架构”
我只是想知道什么会有最好的表现。
假设我们有 3 台物理服务器，每台服务器有 32 核和 64GB RAM，并且应用程序是“标准”asp.net 应用程序。负载平衡已经就位。
设置 1# - 一个应用程序消耗所有 - 一台 IIS 服务器，每台物理服务器上运行 1 个应用程序。 （总共 3 个应用程序“端点”）
设置 2# - 共享资源 - 一台 IIS 服务器，网络场中有 16 个应用程序。 （总共 48 个应用程序“端点”）
设置 3# - 虚拟化 虚拟化：15 个虚拟服务器（总共 45 个应用程序端点）
什么会具有最佳性能，为什么？
I was just wondering what will have the best performance.
Lets say we have 3 physical servers, where each server has 32cores and 64gb ram, and the application is a "standard" asp.net application. Load balancing is already in place.
Setup 1# - One applicaiton consumes all
- One IIS server with 1 application running on each physical server. (total of 3 application "endpoints")
Setup 2# - Shared resources
- One IIS server with 16 applications in a webfarm. (total of 48 application "endpoints")
Setup 3# - Virtualization
Virtualization: 15 virtual servers (total of 45 application endpoints)
What would have the best performance, and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于！很大程度上取决于应用程序正在做什么以及它把时间花在哪里。
但从广义上讲：
如果应用程序是计算绑定的，即从数据库等外部源检索数据所需的时间有限，那么在大多数情况下，设置 #1 可能会最快。 IIS 本身是高度多线程的，赋予它对机器资源的控制权将允许它进行自我调整。
如果应用程序是数据绑定的——即每个请求花费的时间超过（比方说）40%用于获取和等待数据——那么设置＃2可能会更好。对于进行同步进程内数据库访问的编写不太好的应用程序来说尤其如此：即使线程等待数据库访问完成，它仍然在消耗资源。
如此处所述：如何增加线程池线程IIS 7.0 您最终将耗尽线程池线程。但是，正如 MSDN 上所讨论的：http://blogs.msdn.com/b/david.wang/archive/2006/03/14/thoughts-on-application-pools-running-out-of-threads.aspx 通过创建多个 IIS 工作进程实际上只是掩盖了更大的潜在问题的漏洞。
除非有其他原因（例如可管理性），否则我不建议设置 #3，因为在整个虚拟机中管理其他操作系统的开销相当大。
因此：监控您的系统，使用 MiniProfiler (http://code.google .com/p/mvc-mini-profiler/）来找出代码中的问题所在，并尽可能使用异步非阻塞调用。
It depends! Much depends on what the application is doing and where it spends its time.
In broad terms, though:
If an application is compute-bound -- i.e. the time taken to retrieve data from an external source such as a database is limited -- then in most cases setup #1 will likely be fastest. IIS is itself highly multi-threaded and giving it control of the machine's resources will allow it to self-tune.
If the application is data-bound -- i.e. more than (say) 40% of the time taken for each request is spent getting and waiting for data -- then setup #2 may be better. This is especially the case for less-well-written applications that do synchronous in-process databases accesses: even if a thread is sitting around waiting for database access to complete it's still consuming resources.
As discussed here: How to increase thread-pool threads on IIS 7.0 you'll run out of thread pool threads eventually. However, as discussed on MSDN here: http://blogs.msdn.com/b/david.wang/archive/2006/03/14/thoughts-on-application-pools-running-out-of-threads.aspx by creating multiple IIS worker processes you're really just papering over the cracks of larger underlying issues.
Unless there's other reasons -- such as manageability -- I'd not recommend setup #3 as the overhead of managing additional operating systems in entire virtual machines is quite considerable.
So: monitor your system, use something like the MiniProfiler (http://code.google.com/p/mvc-mini-profiler/) to figure out where the issues in the code lie, and use asynchronous non-blocking calls whenever you can.
这实际上取决于您的应用程序，您必须针对每种架构进行设计并测试您的设置的性能。某些应用程序在设置 1 上运行得很快，但在其他设置上则不然，反之亦然。您还可以优化 iis 的性能。关键是您设计用于监视和扩展的应用程序。
It really depends on your application, you have to design for each architecture and performance test your setups. Some applications will run fast on setup 1 and not on the other setups and the other way around. There are many more things you can optimize on performance in iis. The key thing is you design you application for monitoring and scaling.