Résoudre les problèmes de performances Gestion des API Azure dans les appels d’API

Résumé

Cet article explique comment résoudre les problèmes de performances Gestion des API Azure dans les appels d’API, notamment la latence du back-end et les erreurs HTTP 500 et 429. Utilisez ces étapes pour isoler les erreurs et améliorer les temps de réponse de l’API.

Cet article est le quatrième scénario du laboratoire de la série de résolution des problèmes Gestion des API Azure. Veillez à suivre les instructions de configuration du labo en fonction des instructions de la série de résolution des problèmes de gestion des API.

Version du produit d’origine : service Gestion des API
Numéro de base de connaissances d’origine : 4464929

Symptômes

L’API ProductStore dans Gestion des API communique avec le point de terminaison principal (https://productstoreapp.azurewebsites.net) pour créer, lire, mettre à jour et supprimer des enregistrements selon les besoins. Toutefois, vous pouvez rencontrer des problèmes de performances et des exceptions lorsque vous effectuez les opérations d’API suivantes.

• Products_GetAllProducts prend cinq secondes pour retourner les résultats, mais le temps de réponse attendu est inférieur à une seconde.

• Lorsque vous utilisez l’opération de Products_DeleteProduct pour supprimer un produit avec l’un des ID mentionnés précédemment (un à trois), vous obtenez une erreur http 500 - Serveur interne avec le message suivant :

  « Message » : « Une erreur s’est produite ».

• Une opération de mise à jour d’un produit est soumise de façon inattendue à une limitation du débit et entraîne l’erreur HTTP 429 - Trop de requêtes. Cette erreur se produit indépendamment de l’ID de produit et du corps de la demande. Par exemple, si le client met à jour le prix du produit de « soupe tomate » avec l’ID de produit défini sur un à l’aide de l’exemple suivant, il obtient un code d’état HTTP 429.

  ID de paramètre de modèle : 1
     Corps de la demande : {"Name » : « Soup tomate »,"Category » : « Épicerie »,"Price » : 2.45}
     Corps de réponse :
  {
  Limite de débit dépassée. réessayer après un certain temps.
  }

Résolution des problèmes

Lors de la résolution des problèmes de performances, la meilleure façon d’isoler les erreurs consiste à capturer une trace d’inspecteur gestion des API qui indique le temps nécessaire pour chaque section (entrant, back-end et sortant).

latence de Products_GetAllProducts

Si vous analysez la trace de l’inspecteur d’API pour ce problème, vous voyez que le back-end prend le plus de temps (environ cinq secondes). Ce résultat signifie qu’il existe une certaine lenteur ou une opération longue sur le back-end. L’exemple suivant montre le temps de réponse du back-end dans la trace de l’inspecteur d’API :

« source » : « forward-request »,
« timestamp » : « 2018-07-29T16:16:46.6615081Z »,
« écoulé » : « 00:00:05.5844430 »,
« data » : {
« response » : {
« status » : {
« code » : 200,
« reason » : « OK » }

Une fois que vous isolez que la lenteur se produit sur le serveur principal, vous devez examiner le code d’application back-end de l’application API web. Pour les scénarios où vous n’avez pas accès au back-end, vous pouvez implémenter la mise en cache au niveau gestion des API, comme illustré dans l’exemple suivant.

    <?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>

Pour plus d’informations sur la mise en cache, consultez Ajouter une mise en cache pour améliorer les performances dans Gestion des API Azure.

Products_DeleteProduct erreur de serveur interne HTTP 500

Pour résoudre ce problème, suivez la même procédure pour analyser la trace de l’inspecteur d’API Management. Vous voyez probablement un code d’état HTTP 500 sous l’attribut forward-request de réponse.

Ce code d’état signifie que l’API back-end retourne HTTP 500 en raison d’une exception non gérée dans le code principal. Il n’existe aucun problème au niveau gestion des API, comme indiqué dans l’exemple suivant :

demande de transfert (841.060 ms)
{
« response » : {
« status » : {
« code » : 500,
« raison » : « Erreur interne du serveur »
}

Products_PutProduct erreur HTTP 429 trop de requêtes

Dans ce cas, il semble que vous ayez atteint une limite de taux d’appel de l’API. Vérifiez si une politique rate-limit ou rate-limit-by-key est définie au niveau de l’opération.

Si vous ne trouvez aucune stratégie comme celle-ci au niveau de l’opération, sélectionnez Calculer la stratégie effective. Cette action montre toutes les stratégies héritées de différents niveaux, y compris les stratégies au niveau du produit qui peuvent provoquer ce problème.

Vous pouvez voir certaines stratégies implémentées au niveau de l’API qui ne limitent pas réellement le taux d’appel de l’API. Au lieu de cela, il imite ses actions en renvoyant au client une réponse personnalisée à l’aide des stratégies return-response et set-status pour la section Sortant, comme indiqué dans l’exemple suivant :

    <?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>