关于IIS 8 64位可伸缩性问题的ASP .Net 2，经典流水线

问题的相当一般性质的道歉 - 我只是希望有人可以提供一些建议和/或想法，因为我不能兼得！我们运行一个相当大的（35M点击量/月，峰值在170个连接/秒）网站，该网站提供免费的软件下载（严格合法），并且是用ASP .NET 2编写的（VB .Net： （）我们有2个Web服务器，坐在专用的硬件负载均衡器后面，两台服务器都相当笨重，Windows Server 2012 Pro 64位和IIS 8.我们通过使用自定义404页面来解析出所请求的URL和Server.Transfers适当的。因为这个特殊的组件，我们必须运行在经典的管道模式。 数据库明智我们使用MySQL，并有两个复制DBs，读取主要是从奴隶。DB访问是通过一个DevArt库和被广泛缓存。关于IIS 8 64位可伸缩性问题的ASP .Net 2，经典流水线

问题： 我们最近（过去几个月）从运行Windows 2003 Server和IIS6的旧服务器中移出。在这个过程中，我们还升级了Devart组件和MySql（5.1）。从那时起，我们遭遇了间歇性的可扩展性问题，随着我们添加更多内容，这些问题变得更加严重。我们最近将程序数量从2000增加到4000，这导致响应时间从< 300ms增加到超过3000ms（用NewRelic测量）。这在我的脑海中指向DB中的瓶颈（相对不太可能，考虑到广泛的缓存和来自数据库监控）或者书写错误的查询或代码问题。 我们还经常看到尖峰似乎与高速缓存刷新一致，这可能会支持严重写入的查询参数 - 不幸的是，所有高速缓存都是在检索后的x分钟内完成的，因此无法准确定位。 我们所有的缓存都使用锁（像这样的What is the best way to lock cache in asp.net?），所以它可能是一个特定的操作需要一段时间并且备份后面的请求。

问题是......我找不到它！任何人都可以从经验中建议一些工具或方法？我已经尝试过加载测试，我已经对代码进行了描述，我已经逐行阅读了它... NewRelic Pro为我们做了很好的工作，但是试用过期了，出于政治原因，我们还没有购买完整的许可证呢。也许WinDbg是前进的方向？

期待任何见解任何人都可以添加:)

ItalianJob

回答

它不是猜的解决方案是一个好主意。事情会很快变得痛苦或昂贵。你真的应该从一些标准/普通的分流技术开始，并做出一个有教养的决定。在数据驱动的应用程序解决性能问题

标准的过程是这样的：根据需要

1. 评论DB指数（不太可能），并调。
2. 检查资源利用率：CPU，RAM。如果你的CPU已经超频，那么考虑增加/升级CPU或者优化代码或者拆分你的层。如果你的内存已经超出，那么考虑添加内存或拆分你的内存层。我意识到你刚买了新的硬件，但你也改变了操作系统和IIS。所以，所有投注都关闭。花10分钟确认你有足够的CPU和RAM，这样你就可以放心地从列表中删除那些。
3. 检查硬盘使用情况：如果您的队列长度经常超过1（每10秒超过一次），请升级磁盘带宽或扩展磁盘（RAID，多个MDF/LDF，数据库分区）。在每个MySql框中检查它。
4. 检查网络带宽（非常不可能，但请检查它）
5. 代码：a）考虑升级到.net 3.5（或更高版本）。它旨在提供更好的可伸缩性，并具有更好的缓存选项。 b）使用更新/改进的缓存。 c）挑选严苛查询和数据库使用的代码。我对RedGate蚂蚁有非常好的体验，但同样如此。产品也很好。

然后事情变得更具体到您的架构，代码和平台。

Application变量也有一些锁定机制，但它们很少成为锁定的原因。

您可能想要关注您的池回收统计信息。如果您有内存泄漏（或连接泄漏等），则当池重启并重新启动时，IIS可能会冻结。

关于IIS 8 64位可伸缩性问题的ASP .Net 2，经典流水线