2017-06-16 2 views
0

Je lis les données du service distant via HttpWebRequest. Le message JSON reçu est temporairement stocké en tant que List(Of Customer) puis inséré dans une table dans Azure SQL à l'aide de Dapper. L'application s'exécute en tant qu'ASP.NET avec .Net Framework 4.6.2 hébergé dans Azure App Service. Ce sont donc deux étapes:HttpWebRequest expire une fois exécuté après SQL Insert (Dapper)

A. Obtenir des données via requête HTTP et magasin comme List(Of Customer)

B. Insérer List(Of Customer) dans la table des clients dans SQL Azure en utilisant Dapper.

Cela fonctionne bien jusqu'à ce que j'essaie de lire et d'insérer un autre ensemble de données dans la même procédure:

C. Obtenir des données via requête HTTP et magasin comme List(Of Payment)

D. Insérer List(Of Payment) dans la table de paiement dans Azure SQL en utilisant Dapper.

Problème: La deuxième requête HTTP (étape C) expire toujours. J'ai fait plusieurs tests. Voici mes observations:

  1. Les deux requêtes HTTP prennent habituellement 2 à 3 secondes pour être exécutées de manière indépendante.
  2. Modifier l'ordre des étapes en A, C, B, D fonctionne parfaitement. Plusieurs demandes suivantes A, C, A, C, ... fonctionnent également. Cela prouve qu'il n'y a pas de problème de serveur distant.
  3. Le délai d'expiration de la requête HTTP n'apparaît que lorsqu'il est précédé d'une insertion SQL.
  4. J'ai séparé A + B en une fonction et C + D en une autre et les déclenche par deux boutons séparés via l'interface graphique. Timeout arrive.
  5. Lorsque C + D est exécuté après A + B mais avec un délai de 1 à 2 minutes, tout va bien. Il semble que moins de données sont insérées à l'étape A + B, le plus petit délai pour C + D est nécessaire pour exécuter correctement.
  6. Après l'exécution de A + B, toute autre requête HTTP vers le même serveur (comme A) expire toujours, même si l'URL demandée n'existe pas. Peu importe si l'autre requête HTTP a été déclenchée via la même fenêtre de navigateur, l'autre ou même d'un autre PC (session asp.net différente)
  7. Une fois que toute autre requête HTTP mentionnée au point précédent est annulée (fenêtre du navigateur qui l'a déclenchée) sera fermé ou redirigé vers une autre page) sans attendre le timeout et sans retarder de 1 - 2 min, C + D fonctionnera très bien. Même déclenché quelques secondes plus tard. Juste seulement la première demande expire.
  8. J'ai essayé d'augmenter ServicePoint.ConnectionLimit et System.Net.ServicePointManager.DefaultConnectionLimit mais ils ont déjà été réglés sur Int32.MaxValue.

Ceci démontre un certain lien entre les insertions SQL et la requête HTTP suivante. Cependant, cela semble difficile à croire, et je rappelle à un problème plus général comme les fuites de mémoire, etc.

EDIT:

Essayer d'enquêter davantage. En utilisant le scénario original A + B + C + D, une fois que le nombre de lignes renvoyées par la première requête HTTP a été limité, il a commencé à fonctionner. Initialement, le service distant a renvoyé 18 000 lignes. On dirait que 10.000 est le nombre quand il commence à fonctionner (certaines exécutions fonctionnent toujours avec une erreur). Avec 9.000 lignes dans l'étape Un code s'exécute sans aucun problème. Naturellement, les insertions SQL à l'étape B nécessitent moins de temps.

+0

Il semble que ce soit une autorisation de sécurité du service Web qui contrôle la taille maximale des données. Contactez l'administrateur Web qui peut modifier ces paramètres dans web.config. –

+0

Ne peut pas être d'accord car une fois que les insertions de base de données sont ignorées, les données peuvent être lues à partir du serveur distant sans aucun problème. Voir mon observation no. 2. – Megrez7

Répondre

0

La définition de HttpWebRequest.KeepAlive = False pour les demandes de service Web aux étapes A et C a résolu le problème.

Cependant, je ne sais toujours pas pourquoi cela aide et quelle est la raison du problème sous-jacent.

+0

Mais vous avez une avance dans cela. Est-ce un bug? Y a-t-il des nuances subtiles qui vous manquaient? –

+0

@clifton_h Absolument oui. Essayer d'en savoir plus en ce moment. Une suggestion pour le déboguer? – Megrez7