0
我們的團隊在Android中有一個應用程序，並在IIS中託管.NET c＃後端。 在我們的客戶最近，我們已經觀察到突然的，無法解釋的潛伏期有以下情形：性能下降 - IIS或應用程序？
- 沒有任何警告，用戶能夠改變頻道（頻道切換），因爲該產品具有流媒體直播做，他們甚至不能退出應用
- 連接至其他後端（還是AC＃後端）的移動應用程序，工作正常，沒有任何問題
- 經過一段時間（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的，每一個在此應用程序池託管的應用程序，運行良好，無延遲，但仍有可能是我在那裏失蹤的東西 至少， ŝ我懷疑的是，移動應用在兩個方面與解碼器應用不同的事實：
- 首先，移動應用程序從後端的響應以XML格式，解碼器使用JSON。
- 其次，移動應用使用HTTP請求和解碼器使用HTTPS（SSL）
如果有人遇到過類似的問題，他們的幫助將不勝感激。對於您需要的任何其他細節，只需詢問並提供即可。
您確定問題出在軟件上嗎？它可能只是服務器和外部世界之間的一個狡猾的路由器，內部網絡上的IP衝突，有時會擠壓電纜的isp或任何其他網絡相關問題。您所包含的日誌不是直接指向軟件的問題。 –
客戶端遍佈全球，我們嘗試將應用程序連接到兩臺不同的服務器（都由同一個託管公司），並且在這兩個請求中都使用http和https。在所有情況下，我們在每個客戶端都有相同的輸出，延遲和問題（我們所說的話大約有10000個）。最讓我感到恐懼的是，在這個星期裏，它幾乎每天都會發生，事實上它在沒有我們團隊干擾的情況下開始和停止，並且沒有任何警告。 – Ange1
如果它的延遲問題讓我更懷疑關於它在軟件中。測試它的簡單方法是編寫一個小程序，每隔一段時間就對一臺遠程計算機進行一次ping。讓程序記錄延遲並在服務器上運行一天左右。使用該日誌文件，您可以向託管公司證明他們存在問題，或者這不是網絡問題。另外（看你有這麼多活躍用戶），你可能想看看服務器在繁忙時間的cpu/io使用情況。也許硬件只是過載。 –