Partager via

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

  • Article

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

Version du produit d’origine : Gestion des API Service
Numéro de la 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 des besoins. 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, conservez seulement trois produits ayant des ID compris entre 1 et 3.

  • L’une des fonctions d’API Products_GetAllProducts prend 5 secondes pour retourner les résultats, alors 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 HTTP 500 - Erreur interne du serveur 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, en lisant HTTP 429 - Trop de requêtes avec le message d’erreur ci-dessous, quels que soient 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 « Soupe tomate » avec l’ID de produit = 1 avec le corps Json ci-dessous, il obtient le code HTTP 429 status.

    ID de paramètre de modèle : 1
       Corps de la demande : {"Name » : « Tomate soupe »,"Category » : « Épicerie »,"Price » : 2.45}
       Corps de la réponse :
    {
    La limite de débit est dépassée. Réessayez après un certain temps.
    }

Étapes de résolution des problèmes

  • Lors de la résolution des problèmes de performances, la meilleure technique d’isolation des erreurs consiste à capturer [la trace de l’inspecteur APIM qui indique le temps pris dans chaque section (entrant/principal/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 au niveau du back-end.

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

  • Une fois que vous avez isolé le fait que la lenteur se trouve au niveau du back-end, vous devez examiner le code de l’application d’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 interne du serveur), suivez la même procédure d’analyse de la trace de l’inspecteur APIM et nous devrions voir http 500 status code sous l’attribut de réponse « forward-request ».

  • Cela signifie que l’API back-end a retourné HTTP 500 en raison d’une exception non prise en charge au niveau du code back-end. Il n’y a aucun problème au niveau APIM.

    forward-request (841,060 ms)
    {
    « response » : {
    « status » : {
    « code » : 500,
    « reason » : « Internal Server Error »
    }

  • Pour le troisième problème (HTTP 429 - Trop de requêtes), il semble que vous atteignez la limite de débit d’appels d’API. Vous pouvez probablement case activée s’il existe une stratégie « limite de taux » ou « limite de taux par clé » implémentée au niveau de l’opération.

  • Si vous ne trouvez pas ces stratégies 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 si certaines stratégies au niveau du produit peuvent être à l’origine de 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’appels d’API, mais imite son action en renvoyant une réponse personnalisée au client à l’aide des stratégies « return-response » et « set-status » au niveau de 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.