性能慢 - IIS 或应用程序？答案

【问题标题】：slow performance- IIS or application?性能慢 - IIS 或应用程序？
【发布时间】：2016-03-02 11:31:52
【问题描述】：

我们的团队有一个 Android 应用程序，带有 .NET c# 后端，托管在 IIS 中。最近，我们在以下情况下观察到客户突然出现无法解释的延迟：

用户可以在没有任何警告的情况下更改频道（Zapping），因为该产品与直播媒体流有关，他们甚至无法退出应用程序
连接到另一个后端（仍然是 c# 后端）的移动应用程序运行正常，没有任何问题
一段时间后（从第一次事件的 6 小时到最后一次事件的 5 分钟不等），一切都恢复正常。

我启用了失败的请求跟踪日志，看看我是否可以从那里得到任何东西，结果如下：

<failedRequest url="https://ourDNS.com:443/servertime.aspx"
               siteId="1"
               appPoolId="DefaultAppPool"
               processId="22232"
               verb="POST"
               remoteUserName=""
               userName=""
               tokenUserName="NT AUTHORITY\IUSR"
               authenticationType="anonymous"
               activityId="{80013C53-0802-B500-B63F-84710C7967BB}"
               failureReason="TIME_TAKEN"
               statusCode="200"
               triggerStatusCode="0"
               timeTaken="45141"
               xmlns:freb="http://schemas.microsoft.com/win/2006/06/iis/freb"
               >

上面描述的页面是一个简单的页面，首先获取服务器的时区，然后在获取客户的时区（可以从客户端手动设置）后，返回应用程序所在设备的确切日期和时间托管，用于进一步计算流程序，现在正在播放什么等。但是，对于这个页面，它返回一个带有字符串的简单 JSON，它需要超过 45 秒的时间（对我来说这太疯狂了）。目前来自客户端的另一个日志是上面的一个异常：

java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:103)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:191)
at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:82)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:174)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:180)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:235)
at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:259)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:279)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:428)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
at com.framework.utilityframe.webhelper.HttpRequest.getHttpResponse(HttpRequest.java:316)
at com.framework.utilityframe.webhelper.HttpRequest.httpRequest(HttpRequest.java:393)
at com.tibo.webtv.web.TiboLog.logBufferingError(TiboLog.java:319)
at com.tibo.webtv.CustomVideoView$Buffering_Problem.doInBackground(CustomVideoView.java:324)
at com.tibo.webtv.CustomVideoView$Buffering_Problem.doInBackground(CustomVideoView.java:307)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:137)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)

通过阅读不同的论坛，我看到了导致性能泄漏的不同原因，从数据库到 IIS，甚至是应用程序的错误配置。我放弃了数据库作为一个原因，因为：

在出现问题的那一刻，数据库参数完全正常，查询执行时间没有变化，没有等待任务，没有锁定
其次，移动应用程序和解码器应用程序连接到同一个数据库，并且移动应用程序在相同的查询下运行良好

现在，如果我想到 IIS，那么托管在该 AppPool 上的每个应用程序都运行良好且没有延迟，但我仍然可能缺少一些东西至少，让我怀疑的是，移动应用程序与解码器应用程序在两个方面有所不同：

首先，移动应用程序以 XML 格式从后端获取响应，解码器使用 JSON。
二、移动应用使用http请求，Decoder使用https（SSL）

如果有人遇到过类似问题，我们将不胜感激。对于您需要的任何其他详细信息，请询问，我会提供。

【问题讨论】：

您确定问题出在软件上吗？它可能只是服务器和外部世界之间的一个狡猾的路由器，内部网络上的 ip 冲突，您的 isp 有时会挤压电缆或任何其他与网络相关的问题。您包含的日志没有直接指向软件问题。
客户端分散在世界各地，我们尝试将应用程序连接到 2 个不同的服务器（均由同一托管公司提供）中，并在 http 和 https 请求中连接。在所有情况下，我们在每个客户端（我们所说的大约 10000 个）中都有相同的输出、延迟和问题。最让我害怕的是，在这一周里，几乎每天都在发生，而且它的开始和停止都没有我们团队的任何干扰，也没有任何警告
如果它的延迟问题让我更加怀疑它是否存在于软件中。一个简单的测试方法是编写一个小程序，每隔一段时间对远程计算机执行一次 ping 操作。让程序记录延迟并在您的服务器上运行一天左右。使用该日志文件，您可以向托管公司证明他们有问题，或者这不是网络问题。或者（看到您有这么多活跃用户）您可能想查看高峰时段服务器上的 cpu / io 使用情况。也许硬件只是过载了。
你收集到的还不足以揭示问题的方方面面。如果没有同时来自网络层、服务器端和客户端的完整数据，几乎不可能将它们关联起来并找出原因。此类案件不要使用论坛，因为它无法处理如此复杂的案件。
我个人不认识 LeanSentry，但我可以从那里的网站收集到他们监控托管过程。监控应用程序运行状况的有用工具，但它似乎无法检查应用程序与外界的连接方式。至于ping工具我不知道有没有现成的。但是使用 c# 编写一个每 +-10 秒 ping 一次外部地址的应用程序并不难（例如 8.8.8.8 的 google dns）。将时间 + 延迟时间记录到文本文件中。 ping example

标签： c# android asp.net iis

【解决方案1】：

所以，今天，我们的团队进行了另一项测试，其中包括：

应用程序托管在一台服务器上，数据库托管在另一台服务器上
应用程序和数据库托管在完全不同的服务器（Azure 环境）中

在这两种情况下，结果都是一样的：服务出现延迟和问题。问题既不在后端也不在服务器。首先，Java 应用程序在将日志保存到另一台服务器时错误地执行了同步任务（专用，完全有可能保留尽可能多的数据）。其次，日志服务器有一个完整的 HDD，只有超过 1 TB 的 DB 日志，所以当应用程序执行这些同步任务（这是第一次调用，在与通道进行任何交互之前）时，它们会收到 Socket 异常。因此，也许对于可能看到此帖子的其他人：请始终检查您的应用程序中的任务，并始终检查与您的应用程序相关的任何服务器！！！非常感谢：D

【讨论】：