诊断 ASP.NET 连接问题的好方法是什么？
虽然从表面上看这个问题应该出现在 serverfault.com 上，但我有理由先在这里发帖。
我开发了一个 ASP.NET 2.0 Web 应用程序。 就在最近，由于使用量较大，在回发或 AJAX 调用过程中出现了错误（无法连接到服务器）。 然而，错误是间歇性的，并且服务器在 CPU、IO 或 RAM 方面没有显示出负载迹象。
我的第一直觉是“网卡故障”，但我是一名软件开发人员，我不喜欢责怪我的工具。 99% 的情况下，错误是人为错误而不是硬件错误。
Rackspace（我们的提供商）表示没有网络错误，服务器日志也没有显示任何后果。
正如您所期望的，在本地验证系统上，软件的运行就像一场梦。
我的问题是您从哪里开始在 serverfault.com 上查找以及在哪里停止并询问？
（我想我正在寻找专家的想法清单）
Whilst on the surface this question looks like it should be on serverfault.com I have a reason for posting here first.
I developed an ASP.NET 2.0 web application. Just recently with heavier usage there have been errors whilst (Cannot connect to server) in the middle of an post back or AJAX call. However the errors are intermittent and the server is showing not signs of load in terms of CPU, IO or RAM.
My first instinct says "Network card fault", however I am a software developer and I do not like to blame my tools. 99% of the time a bug is human error rather than hardware.
Rackspace (our provider) say there are no network errors and the server logs show nothing of consequence.
On the local validation systems the software runs like a dream, as you would expect.
My question is where do you start looking and where do you stop and go ask on serverfault.com?
(I guess I am looking for an idea checklist from experts)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看服务器事件日志，尤其是来自“ASP.NET”事件源的事件。 另外，请查看 ASP.NET 性能计数器，尤其是“请求”计数器。
这听起来像是您的工作线程用完了，可能是因为您的请求花费的时间太长。 您可能会发现，只有某些请求在数据库操作等方面花费了太长时间，在这种情况下，您可以通过使这些页面异步来缓解问题。
Take a look in the server event log, especially for events from the "ASP.NET" event source. Also, look at the ASP.NET performance counters, especially the "Request" counters.
This sounds like you're running out of worker threads, possibly because your requests are taking too long. You may find that it's only certain requests that take too long with database operations or such, in which case you'll be able to mitigate the problem by making those pages asynchronous.
我将执行以下操作来尝试隔离它：
使用 watchmouse.com 等服务从不同位置监视您的应用程序。
这应该可以告诉您是否是网络问题。 （可能不受 Rackspaces 控制。）
获取 HTML 和 HTML 的示例。 发生错误时页面的 Javascript。
这应该有助于确定它是否是代码。
获取错误发生的准确时间。
您可以将这些数据提供给机架空间来监视日志，并查看您自己的这些时间的日志记录。
也正如 John 所说，请查看您的事件日志和计数器以确定您的终端是否存在问题。
同样正如 John 所说，请查看您的事件日志和计数器以确定您的终端是否存在
I would do the following to attempt to isolate it:
Use a service like watchmouse.com to monitor your application from different locations.
This should hopefully give you an indication if it's a network issue. (Possibly one outside of Rackspaces control.)
Get an example of the HTML & Javascript of a page, when the error occurs.
This should help determine if it is the code.
Get exact times when the error occurs.
You can give these to rackspace to monitor logs, as well as look at your own logging for these times.
Also as John says, look at your event logs and counters to determine if there is a problem on your end.