我正在一个专用的服务器上运行一个ASP.Net webapp，并且最近对服务器硬件做了一个重要的更新。 令我惊讶的是绝对没有性能提升。
旧的服务器：单个xeon x3220 2演示Windows 2003 IIs6数据库在单独的服务器上运行，旧xeon。
新的服务器：32演示ram raid 1 0 SSDs Windows 2008标准IIs7双xeon x5660 DB运行在同一台机器上
关于新服务器的一切都是好得多，但没有改善。 我们正在更新Web应用程序本身，但我想知道从服务器/ IIS7configuration的angular度来做什么可以加速这个事情。 对于这个更新，这个webapp没有任何改进似乎是不可能的。
首先，我们需要澄清你的意思没有改善。 性能优化要记住的关键是衡量。
如果您的网页只需要几毫秒的时间就可以加载，那么现在他们可能要花费1或2毫秒的时间。 只是因为人眼不明显并不意味着没有发生。
当然，在页面加载速度和服务器可以处理多less个并发请求之间，性能也是不同的。 您可能会发现，即使服务器似乎响应相同，它可以采取更多的同时用户。
如果你的应用程序是一个基本的CRUD应用程序，那么添加更多的处理器和内存可能不会有什么不同，因为这不是你的瓶颈所在。 我曾经期望将数据库移动到同一台计算机，以增加一点，但这又取决于如何衡量它。
我的build议是使用性能计数器来衡量服务器的负载，分析IIS日志来检查页面的响应时间，并找出问题所在。
服务器升级是否完成，是因为应用程序性能不够好？
是的，你所描述的所有事情都应该能带来更快的体验。 他们没有暗示……（震惊），它不是具有可伸缩性问题的平台。
你需要分析你的应用程序。 IIS可以在没有任何严格的优化的情况下每秒提供大量的请求，而且不太可能你已经改变了任何默认设置（对吧？），所以…离开了应用程序。 或者是应用程序框架（.Net，对吗？已经编译debug = false了吗？）
正如你现在在IIS 7上，我的build议是，你看第一个地方是失败的请求跟踪（安装跟踪组件），然后挂接一个规则，目标任何响应代码（100-599），得到FREB日志并看看在哪里花费的时间（精简视图是好的）。 如果您看到某个模块花费的时间过长，请对其进行调查。
看看networking日志 – 你看到更多的请求比你想象的要多吗？ （当考虑性能优化时，回答“是”的频率令人惊讶）。 到时候的结果表明是的，服务器认为性能很慢？
在页面上有JavaScript吗？ 这可能是客户的performance感知问题吗？
如果这样做不能提供足够的深度，请查看应用程序中的任何一个，或者连接一个分析器，以确定所花费的时间。
事情是，如果更新硬件没有效果 – 看起来像是一个严重的升级 – 你不是硬件绑定 。 你可能从来没有。 要求“一般的加速调整”不是你所需要的 – 你需要测量，改变，testing，迭代。 一旦找出原因，解决方法很简单。 但是你还没到。