分析实时 = 45 秒，但线程时间 = 0.387 秒什么会导致这种差异？
因此，我们的托管提供商最近将我们的测试服务器从一个环境迁移到另一个虚拟化环境。迁移后，测试环境中的某些事情变得非常慢。
例如登录远程桌面很慢，不使用远程桌面，只是登录。还有一些平时跑得像风一样的asp.net应用程序现在跑得像乌龟一样。在对造成这种减速的原因进行了大量争论之后，我开始调查实际问题。
最后一个有趣的发现是我在测试服务器上安装 dotTrace 时发现的。运行一个我知道会表现得很差的页面，对于执行该麻烦页面的工作的线程，我得到了以下（高级）结果：
Real/wall time: 45538 ms
Thread time: 375 ms
据我所知，这意味着该线程花费了很长的时间没有被执行。 我自己的理论是，虚拟环境优先考虑其他服务器的工作而不是我的服务器。这可能是原因吗？你有什么想法？
注意：如果您需要更多详细信息（例如实际痕迹），如果您提出要求，我可以毫无问题地提供它们。
编辑：更多详细信息！ 跟踪中最昂贵的调用是：
1 次调用 KeyInfoX509Data.ctor(X509Certificate, X509IncludeOption)：30014 ms
1 次调用 SignedXml.ComputeSignature：15045 毫秒
So, our hosting provider recently moved our test server from one environment to another, virtualized environment. After the move some things on the test environment got extremely slow.
For example logging in to remote desktop was slow, not using remote desktop, just logging in. Also some asp.net applications that usually runs like the wind are now running like a tortoise. After a lot of debate as to the cause of this slowdown I began investigating the actual problem.
The last interesting find was found when I installed dotTrace on the test server. Running a page I knew would perform badly I got the following (high-level) results for the thread that performed the work for the troublesome page:
Real/wall time: 45538 ms
Thread time: 375 ms
As far as I know this means that the Thread spends an awful long time not being executed.
My own pet theory is that the virtual environment is prioritizing other servers work over my server. Could that be the cause? What are your thoughts?
Note: If you need more details like the actual traces I have no problem handing them out if you ask.
Edit: More details!
The most expensive calls in the trace are:
1 call to KeyInfoX509Data.ctor(X509Certificate, X509IncludeOption): 30014 ms
1 call to SignedXml.ComputeSignature: 15045 ms
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对我来说，这种差异就是 IO 等待问题的根源。最有可能的是磁盘或网络，尽管 CPU 也不会让我感到惊讶。
由于它似乎专门用于读取证书，因此我会调查是否有另一个虚拟机/服务在磁盘或网络上变得贪婪。不断下载大文件或频繁访问的数据库可能是根本原因。
可以肯定的是，您必须查看共享您的硬件的所有虚拟机上的相应活动，以及可能到达您的测试箱以及从您的测试箱到外部的网络跟踪。这可能只有 ISP 才能做到（因为它本质上是一个跨客户交互问题）。
根据 VM 服务器和硬件，它可能是可调整的设置，也可能不是。如果不是，您可能无能为力。
无论如何，我同意你的理论：这可能不是你的应用程序的问题，而是你的提供商的问题。如果您对 ISP 有影响力，我会将其交给他们来解决和/或调查更换提供商的问题。绕过它的黑客成本可能大大低于让他们为您提供一些硬件或与可以为您提供所需服务的提供商合作的成本。
To me, that discrepancy screams of IO wait issues. Either disk or network, most likely, though CPU wouldn't surprise me either.
Since it seems to be specifically in reading the certificate, I'd look into whether there's another VM/service getting greedy on either disk or network. Perpetually downloading big files or a heavily accessed database might be the root cause.
To be sure, you'd have to look at the corresponding activity on all the VMs that share your hardware and possibly the network traces getting to your test box and from your test box to the outside. This is likely something that only the ISP can do (since it's essentially a cross-customer interaction issue).
Depending on the VM Server and the hardware, it may be a tweakable setting or it may not be. If it isn't, there may not be anything you can do about it.
At any rate, I agree with your theory: it's likely not a problem with your application, but rather an issue with your provider. If you've got any clout with the ISP, I'd kick it back to them to resolve and/or investigate changing providers. The cost of hacking around it is likely to substantially dwarf getting them to just dedicate you some hardware or going with a provider that can give you the service you need.
所以结果是安全/网络/dns问题。服务器上的 DNS 注册之一不正确。这导致在尝试查找 AD 服务器时返回错误的 IP。这导致请求 AD 信息时超时，从而再次导致一些其他问题。所有这些问题仅在请求某些页面时表现为长时间停顿。
So it turned out to be a security/network/dns problem. One of the DNS registrations on the server was incorrect. This led to a wrong IP being returned when it tried to lookup the AD server. That then led to timeouts when requesting AD information which then again led to some other problems. All of these issues only showed themselves as a long pause when requesting certain pages.