Непоследовательность запросов в ASP.NET WebAPI и IIS

Ответ 1

Это не проблема с angular, но вот как я могу решить эту проблему:

• Используйте что-то вроде этого chrome extension для клиента REST API, чтобы делать запросы к вашей конечной точке. (вы также можете использовать что-то вроде: http://jmeter.apache.org/, но это сложнее настроить)
• Запустите это 20 раз и сохраните время.
• Очистить базу данных и просто заполнить таблицы, которые вам нужны для этого запроса - всего несколько строк данных.

• Запустите инструмент 20 раз - сохраните время. Согласуются ли они? Если в этот момент они не согласуются, я бы посмотрел на код как на виновника.

  • Вы вызываете какие-либо внешние службы?
  • является ли служба, выполняющая что-либо еще при загрузке данных, помимо выполнения запроса?
  • используйте профайлер, например dotTrace, чтобы узнать, что занимает больше времени, чем нужно. (на самом деле вы должны использовать это с самого начала)

• Если время по-прежнему непротиворечиво, загрузите больше данных в базу данных до тех пор, пока время не станет непоследовательным. Затем профилируйте запросы и начните их оптимизацию.

Прямо сейчас, насколько несовместимы тайминги, я бы предположил, что служба делает что-то еще при загрузке этих данных: внешний вызов службы.. что-то.

Ответ 2

Хорошо, было бы очень полезно, если бы вы могли поделиться с нами кодом, который выполняется на сервере, и какова разница между нечетными и четными запросами.

Я делаю здесь много предположений, поэтому, пожалуйста, извините любые глупые ошибки.

Я видел такое поведение до, в этом случае это связано с SqlServer Caching.

В кратчайшие сроки вы можете найти много информации об этом в Интернете, прежде чем выполнять запрос, который движок SqlServer выполняет некоторые вычисления, и решить, какой оптимальный способ получить данные для этого запроса. Это добавляет дополнительную нагрузку на ваше время запроса, SqlServer знает это и кэширует этот план выполнения, чтобы он мог повторно использовать его позже.

Я не знаю всех подробностей об этом, но если бы я должен был догадаться, я бы сказал, что что-то делает недействительным этот кеш, поэтому его нужно пересчитывать каждый раз в то время. Общими причинами этого могут быть разные предложения order by и join, которые могут произойти в зависимости от данных, отправленных методу.

Другая возможность заключается в том, что сам результат кэшируется, и через некоторое время он становится недействительным.

Как я уже сказал, это дикое предположение, не глядя на код, но я действительно думаю, что было бы неплохо проверить это.

Один простой способ проверить это - проверить, не меняется ли время, если вы отправляете один и тот же запрос снова и снова, повторно, без отправки другого. Тем временем

Надеюсь, что это поможет.

Ответ 3

Вы пишете "те же самые запросы", но что именно происходит в этих запросах?

Вы запрашиваете базу данных SQL-сервера?

Как выглядит выражение?

Что еще вы делаете в своем запросе?

Есть так много возможных влияний, поэтому для того, чтобы сделать обоснованное предположение, мне понадобится более подробная информация о ваших запросах.

Ответ 4

Несколько вещей, чтобы проверить/отметить:

1). Установили ли вы Glimpse? http://getglimpse.com/, если бы я не установил это из nuget, это даст вам представление о полном конвейере и поможет вам отслеживать, куда идут эти задержки из.

*** более общие рекомендации по производительности ниже **

2). у вас есть отладка отключена в веб-конфигурации для публикации на вашем сервере? если не сделать это первым. Я ожидал бы, что ваш локальный компьютер будет немного отличаться от сервера, я полагаю, вы используете iis express на своем локальном компьютере? который имеет разные характеристики производительности, чем iis на сервере (я бы этого не ожидал), поэтому не следует чрезмерно руководствоваться этим. Glimpse будет вашим лучшим другом здесь:-)

3). Как и выше, то же самое относится к состоянию сеанса. Если у вас нет оснований для его использования, отключите его (по умолчанию он включен) - в некоторых сценариях это может быть убийца производительности.

Ответ 5

Скорее всего, вы видите одно из следующих:

• Перезагрузка/очистка пула приложений IIS (это может произойти, когда настройка будет перезаписана, когда все будет закрыто)

• Коллекция GC GC (маловероятная)

• Задержки, связанные с SQL Server (выполнение кеширования выполнения запросов и данные в памяти)

Чтобы исключить действие # 3, попробуйте запустить профилировщик SQL Server одновременно с файрволом и посмотрите, можете ли вы определить задержку из базы данных (либо она подтвердит это в базе данных, либо подтвердит, что база данных отвечает то же самое в обоих случаях).

С# 2 не так много, что вы действительно можете сделать, кроме как попытаться уменьшить объем памяти и повторное использование структур данных; но, как упоминалось выше, это вряд ли может быть причиной проблемы.

С# 1 вы можете внести изменения в конфигурацию IIS, чтобы убедиться, что этого не происходит.