2017-05-27 5 views
1

J'ai un test de charge Visual Studio qui passe à travers les pages d'un site Web, mais ont connu de grandes différences dans les performances lors de l'utilisation d'un équilibreur de charge. Si j'exécute les tests directement sur le serveur Web 1 en court-circuitant l'équilibreur de charge, j'obtiens un temps de chargement de page moyen inférieur à 1 seconde pour 100 utilisateurs à titre d'exemple. Si je dirige le même test sur l'équilibreur de charge avec 2 serveurs Web derrière, alors j'obtiens un temps moyen de chargement de la page d'environ 30 secondes - il commence rapidement mais se détériore ensuite. Ceci est étrange car j'ai maintenant 2 serveurs Web charge équilibrée au lieu d'utiliser 1 direct donc je m'attends à être en mesure d'augmenter la charge. Je suis en train de tester cela avec Azure Web Application Gateway maintenant et Azure VMs. J'ai déjà rencontré le même problème avec une configuration NGinx, je pensais que c'était dû à cette configuration mais maintenant je trouve que j'ai la même chose sur Azure. Toutes les pensées seraient géniales.Application Performance Web Azure passerelle avec le test de charge

+0

Quelle est la taille de la passerelle d'application web? – CtrlDot

+0

Démarré avec la passerelle WAF moyenne, 2 instances. Changé ceux-ci à grande et obtenu exactement les mêmes résultats d'une charge de 15min 100 utilisateurs. –

+0

J'ai exactement la même chose. L'avez-vous résolu? Je soupçonne que le WAF est à l'origine du retard, donc je suis en train de minimiser l'ensemble des règles qu'il applique (ou désactiver complètement), mais pas sûr que cela aiderait – Muzikant

Répondre

0

J'ai dû désactiver complètement le pare-feu pour obtenir des performances constantes. J'ai aussi rencontré d'autres problèmes avec le pare-feu, où il nous a donné des erreurs de taille d'entité max à partir d'un module de sécurité et après avoir discuté avec le support Azure cette taille de l'entité ne peut pas être configuré de manière à maintenir le pare-feu signifierait quelques grandes pages ne fonctionnerait plus et obtenir cette erreur. Cela s'est passé même si toutes les règles étaient désactivées, j'ai passé beaucoup de temps à expérimenter différentes règles on/off. Les règles d'injection SQL ne semblent pas aimer notre site de formulaires Web ASP.NET. J'ai maintenant simulé 1 000 utilisateurs simultanés répartis entre deux agents de test et la performance était bonne pour notre site, avec un temps de chargement de page moyen inférieur à une seconde.

0

Voici une liste des choses qui m'a aidé à améliorer la même situation:

  • Ajouter auditeur non-SSL et l'utiliser (par exemple HTTP au lieu de HTTPS). Il est évident que ce n'est pas la solution conseillé mais peut-être que peut vous donner un indice (déchargez SSL aux serveurs de pool back-end? Ajouter plusieurs instances de passerelle?)
  • règles Désactiver WAF (légère amélioration)
  • Désactiver WAF + Ajouté instances plus passerelle (augmenté de 2 à 4 dans mon cas) - RÉSOLU LE PROBLÈME!