Partager via

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

  • Article

Se référant au blog sur Azure Gestion des API Série de résolution des problèmes, il s’agit du quatrième scénario du labo. Vérifiez que vous avez suivi les instructions de configuration du labo en fonction de cela, pour recréer le problème.

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

Symptômes

L’API ProductStore dans APIM communique avec le point de terminaison principal (https://productstoreapp.azurewebsites.net) pour créer, lire, mettre à jour et supprimer facilement des enregistrements en fonction et quand cela est nécessaire. Toutefois, vous pouvez rencontrer des problèmes de performances et des exceptions lors de l’appel des opérations d’API répertoriées ci-dessous. Pour faciliter les tests, gardez seulement trois produits ayant des ID allant de 1 à 3.

  • L’une des fonctions d’API Products_GetAllProducts prend 5 secondes pour retourner les résultats, tandis que le temps de réponse attendu est inférieur à une seconde.

  • Lors de la suppression d’un produit ayant l’un des ID mentionnés ci-dessus (1 à 3), vous obtenez une erreur http 500 - Serveur interne avec le message ci-dessous en appelant Products_DeleteProduct opération.

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

  • Products_PutProduct opération qui met à jour un produit est limitée de manière inattendue, lève http 429 - Trop de requêtes avec le message d’erreur ci-dessous, quel que soit l’ID de produit et le corps de la demande, que vous envoyez dans la requête. Par exemple, si le client met à jour le prix du produit de « Tomate Soupe » ayant l’ID de produit = 1 avec le corps Json ci-dessous, il obtient le 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.
    }

Étapes de dépannage

  • Lors de la résolution des problèmes de performances, la meilleure façon dont la technique d’isolation des pannes capture [trace de l’inspecteur APIM qui montre le temps nécessaire à chaque section (entrant/ back-end/ sortant).

  • Si vous analysez la trace de l’inspecteur d’API pour le premier problème, vous remarquerez que la section back-end prend la plupart du temps (environ 5 secondes), ce qui signifie qu’il y a une certaine lenteur ou une opération de longue durée sur le serveur principal.

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

  • Une fois que vous avez isolé que la lenteur se trouve au niveau du back-end, 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 APIM comme ci-dessous. Découvrez comment implémenter des stratégies de mise en cache pour améliorer les performances dans Azure Gestion des 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>

  • Pour le deuxième problème (HTTP 500 - Erreur de serveur interne), suivez la même procédure d’analyse de la trace de l’inspecteur APIM et nous devrions voir le code d’état HTTP 500 sous l’attribut de réponse « forward-request ».

  • Cela signifie que l’API back-end retournée HTTP 500 en raison d’une exception non gérée s’est produite au niveau du code principal, il n’existe aucun problème au niveau APIM.

    forward-request (841.060 ms)
    {
    « response » : {
    « status » : {
    « code » : 500,
    « raison » : « Erreur interne du serveur »
    }

  • Pour le troisième problème (HTTP 429 - Trop de requêtes), il semble que vous atteignez la limite du taux d’appel de l’API. Vous pouvez probablement vérifier s’il existe une stratégie « rate-limit » ou « rate-limit-by-key » implémentée au niveau de l’opération.

  • Si vous ne trouvez aucune stratégie de ce type au niveau de l’opération, cliquez sur le bouton Calculer la stratégie effective , qui affiche toutes les stratégies héritées de différents niveaux, comme vous pouvez avoir des stratégies au niveau du produit qui peuvent provoquer ce problème.

  • Ici, vous devez remarquer que certaines stratégies sont implémentées au niveau de l’API, ce qui ne limite pas vraiment le taux d’appel de l’API, mais imite son action en retournant une réponse personnalisée au client à l’aide des stratégies « return-response » et « set-status » dans la section sortante.

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

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.