Наша команда имеет приложение на Android с бэкендом .NET C#, размещенным в IIS. В последнее время мы наблюдали внезапные и необъяснимые Задержки в наших клиентах со следующим сценарием:низкая производительность - IIS или приложение?
- без какого-либо предупреждения, пользователи дают возможности изменить канал (выгорание), так как продукт должен делать с живой Media Streaming, и они не могут даже выйти из приложения
- Мобильное приложение, подключенное к другому серверу (по-прежнему aC# backend), работает нормально, без проблем
- Через некоторое время (которое варьируется от 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 секунд (для меня это безумие). Другой журнал со стороны клиента в данный момент является одним Exception, как описано выше:
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 и даже расконфигурация применения. Я отбросили базу данных в качестве причины, потому что:
- На данный момент проблемы, параметры базы данных были абсолютно нормально, никаких изменений в запросах выполнения времени, никаких задач ожидания, нет ни блокировки
- Во-вторых, мобильный и Decoder приложение подключается к одной и той же базе данных, а мобильное приложение работает отлично с теми же запросами
Теперь, если я думаю о IIS, каждое приложение, размещенное в этом AppPool, работает нормально и без задержек, но все же там может быть что-то мне не хватает И, по крайней мере, что-то, что делает S меня подозрительным является тот факт, что мобильное приложение отличается двумя способами с применением Decoder:
- Во-первых, мобильное приложение принимает ответы от Backend в формате XML, то декодер использует JSON.
- Во-вторых, мобильное приложение использует запросы HTTP, и декодер использует HTTPS (SSL)
Если кто испытал подобные проблемы, их помощь будет высоко оценен. И для любой другой детали, в которой вы нуждаетесь, просто спросите, и я предоставлю.
Вы уверены, что проблема в программном обеспечении? Это может быть просто извращенный маршрутизатор между сервером и внешним миром, ip-конфликты во внутренней сети, ваш isp, который иногда скручивает кабель или любую другую связанную с сетью проблему. Журналы, которые вы включили, прямо не указывают на программное обеспечение в качестве проблемы. –
Клиенты разбросаны по всему миру, и мы попытались подключить приложение на двух разных серверах (как одной хостинговой компанией), так и в обоих запросах http и https. во всех ситуациях у нас был одинаковый выход, латентность и проблема в каждом из клиентов (около 10000, как мы говорим). Меня больше всего пугает тот факт, что на этой неделе это произошло почти каждый день, и тот факт, что он начинается и останавливается без какого-либо вмешательства со стороны нашей команды, и без каких-либо предупреждений. – Ange1
Если проблемы с задержкой, это заставляет меня еще больше возражать о том, что он находится в программном обеспечении. Простой способ проверить это - написать небольшую программу, которая так часто пингует удаленный компьютер. Попросите программу зарегистрировать задержку и запустить ее на вашем сервере в течение дня или около того. С помощью этого файла журнала вы можете либо доказать своей хостинговой компании, что у них есть проблема, либо что это не сетевая проблема. В качестве альтернативы (учитывая, что у вас так много активных пользователей), вы можете захотеть взглянуть на использование процессора/io на сервере в часы пик. Возможно, оборудование просто перегружено. –