Поделиться через

Устранение проблем с производительностью вызовов API

  • Статья

Ссылаясь на блог в Azure Управление API серии устранения неполадок, это четвертый сценарий лаборатории. Убедитесь, что вы выполнили инструкции по настройке лаборатории, чтобы повторно создать проблему.

Исходная версия продукта: служба Управление API
Исходный номер базы знаний: 4464929

Симптомы

Api ProductStore в APIM взаимодействует с серверной конечной точкой (https://productstoreapp.azurewebsites.net) для упрощения создания, чтения, обновления и удаления записей по мере необходимости. Однако при вызове операций API, перечисленных ниже, могут возникнуть некоторые проблемы с производительностью и исключениями. Для простоты тестирования сохраните только три продукта с идентификаторами в диапазоне от 1 до 3.

  • Одна из функций API, Products_GetAllProducts занимает 5 секунд, чтобы вернуть результаты, в то время как ожидаемое время отклика меньше секунды.

  • При удалении продукта с указанными выше идентификаторами (от 1 до 3) возникает ошибка HTTP 500 — внутренняя ошибка сервера с приведенным ниже сообщением путем вызова операции Products_DeleteProduct .

    {
    "Сообщение": "Произошла ошибка".
    }

  • Products_PutProduct операция, которая обновляет продукт, неожиданно регулируется, вызывая http 429 — слишком много запросов со следующим сообщением об ошибке независимо от идентификатора продукта и текста запроса, который отправляется в запросе. Например, если клиент обновляет цену продукта "Томатный суп" с идентификатором продукта = 1 с приведенным ниже текстом Json, он получает код состояния HTTP 429.

    Идентификатор параметра шаблона: 1
       Текст запроса: {"Name": "Томатный суп", "Категория": "Продуктовые продукты", "Цена": 2.45}
       Текст ответа:
    {
    превышено ограничение скорости. Повторите попытку через некоторое время.
    }

Действия по устранению неполадок

  • При устранении неполадок с производительностью лучший способ изоляции сбоя позволяет записывать [трассировку инспектора APIM, которая показывает время, затраченные в каждом разделе (входящий/ внутренний сервер или исходящий трафик).

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

    Source: "forward-request",
    "метка времени": "2018-07-29T16:16:46.6615081Z",
    "прошло": "00:00:05.584430","data": {
    "response": {
    "status": {
    "code": 200,
    "причина": "ОК"
    }

  • После изоляции медленности серверной части необходимо изучить код серверного приложения веб-API. В сценариях, когда у вас нет доступа к серверной части, можно реализовать кэширование на уровне APIM, как показано ниже. Узнайте, как реализовать политики кэширования для повышения производительности в Azure Управление API.

    <?xml version="1.0" encoding="UTF-8"?>
<policies>
   <inbound>
      <base />
      <cache-lookup vary-by-developer="true" vary-by-developer-groups="true" must-revalidate="true" downstream-caching-type="public" />
   </inbound>
   <backend>
      <base />
   </backend>
   <outbound>
      <base />
      <cache-store duration="60" />
   </outbound>
   <on-error>
      <base />
   </on-error>
</policies>

  • Во второй проблеме (ошибка внутреннего сервера HTTP 500 — внутренняя ошибка сервера) выполните ту же процедуру анализа трассировки инспектора APIM, и мы должны увидеть код состояния HTTP 500 в атрибуте ответа forward-request.

  • Это означает, что внутренний API вернул HTTP 500 из-за некоторых необработанных исключений в коде серверной части, проблемы на уровне APIM не возникают.

    forward-request (841.060 мс)
    {
    "response": {
    "status": {
    "code": 500,
    "причина": "Внутренняя ошибка сервера"
    }

  • Для третьей проблемы (HTTP 429 — слишком много запросов) похоже, что вы бьете ограничение частоты вызовов API. Вероятно, можно проверить, существует ли какая-либо политика "rate-limit-by-key" или "rate-limit-by-key", реализованная на уровне операции.

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

  • Здесь следует заметить, что некоторые политики реализованы на уровне API, которые не на самом деле ограничивают частоту вызовов API, но имитируют его действие, возвращая настраиваемый ответ клиенту с помощью политик возвращаемого ответа и "set-status" в разделе исходящего трафика.

    <?xml version="1.0" encoding="UTF-8"?>
<outbound>
   <!--base: Begin Api scope-->
   <return-response>
      <set-status code="429" reason="Too many requests" />
      <set-body><![CDATA[{

Rate limit is exceeded. Try again after some time.

}]]></set-body>
   </return-response>
   <!--base: End Api scope-->
</outbound>

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.