Désolé s'il s'agit d'une nouvelle question ...
J'ai entendu des histoires de Netflix et de Twitter capables de dupliquer le trafic Web entre deux infrastructures distinctes: l'une est celle faisant autorité / de confiance qui revient à l'utilisateur; et l'autre est une infrastructure «fantôme» ou de test qui pense qu'elle revient à l'utilisateur mais ne le fait pas. Il s'agit de tester l'infrastructure secondaire à une charge et à un moment réels.
Je suis presque sûr qu'il y a un mot pour décrire cela, mais «bridge» ne semble pas être le bon, pas plus que «rejouer».
Quelqu'un peut-il m'aider avec le nom de cette technique et / ou quels outils peuvent être utilisés pour y parvenir?
Je suppose que je devrais ajouter que j'ai entendu parler de techniques qui sont effectivement en train de «rejouer les journaux», mais c'est vraiment difficile à obtenir à des vitesses / distributions réelles.
Et, nous n'essayons pas de vérifier la `` justesse '' de la sortie, mais assurez-vous simplement que nous ne voyons pas d'erreurs / traces de pile / etc. dans la nouvelle infrastructure.
la source
Réponses:
J'appellerais cela "test de charge via la relecture de session", personnellement. Je ne connais pas de terme fourre-tout simple pour ce type de technique de test.
La stratégie de base que j'ai vue utilisée pour ce type de test de charge consiste à ingérer des fichiers journaux à partir du système de production et à les relire sur un système de test.
Vous pouvez utiliser des outils tels que JMeter ou Apache Bench pour relire les demandes à partir des fichiers journaux. Si vous cherchez à rejouer des interactions client / serveur très complexes (avec des détails de synchronisation spécifiques basés sur le flux de journal d'origine) dans l'espoir de vraiment exercer les entrailles de votre application (à la recherche de conditions de concurrence, de bugs liés au timing, etc.), vous pourriez regardez comment écrire des outils de test spécifiques à l'application qui simulent les clients à grande échelle.
Vous ne pourrez pas simplement capturer des cargaisons de trafic réseau brut et le "rejouer" avec n'importe quel protocole TCP ou IP. Les numéros de séquence TCP ne correspondront pas au trafic capturé d'origine et cela ne fonctionnera pas. Les captures de couche IP vont être problématiques car vos clients simulés devront répondre pour l'adresse IP de l'expéditeur capturé. Vous feriez mieux de capturer le trafic plus près de la couche 7 et de l'utiliser pour rejouer les sessions, sinon vous envisagez également d'écrire un simulateur TCP. (Je pourrais imaginer utiliser quelque chose comme
tsharkpour extraire les données et le timing de la couche 7 d'un flux TCP et les rejouer, par exemple.)La simple relecture du trafic réseau simule la charge mais ne capture pas nécessairement les défauts. Votre client simulé devra recevoir des réponses du serveur de test et les analyser pour vérifier si vous souhaitez tester en charge tout test auquel l'application répond correctement. Étant donné que votre application va générer des données de réponse dynamique, il est peu probable que votre client simulé puisse simplement comparer la réponse du serveur de test à la réponse consignée du serveur de production. C'est là que vous allez commencer à écrire un faisceau de test spécifique à votre application et à sa sortie.
la source
Vous utilisez un service comme BrowserMob qui simule un grand nombre de personnes accédant simultanément à votre site Web. Ces services ne rejouent pas le trafic enregistré, car il vous manquerait alors le côté client de la conversation. Par exemple, vos serveurs essaieraient d'envoyer des paquets à des ordinateurs sur Internet qui ne s'attendent pas à les recevoir. Mais ce que ces entreprises font, c'est étudier les journaux (généralement au niveau de l'application, pas au niveau des paquets) et utiliser ces informations pour déterminer sur quelles pages les gens cliquent, à quelle fréquence et dans quel ordre. Ces données sont utilisées pour écrire des scripts / macros que BrowserMob répète ensuite.
ApacheBench, comme mentionné par un autre utilisateur, n'est pas vraiment utilisé de nos jours. Il était plus utile il y a 10 ans lorsque vous deviez simplement déterminer à quelle vitesse un document HTML statique ou JPEG peut être servi sous une lourde charge. Ce n'est pas très différent d'un groupe de personnes qui cliquent sur recharger, recharger, recharger encore et encore sur leur navigateur Web. Vous avez besoin de quelque chose d'un peu plus intelligent lorsque vous testez une application Web qui a un flux de travail plus complexe.
la source
Je ne pense pas que vous puissiez le faire au niveau d'une couche réseau, bien que vous puissiez éventuellement obtenir un noyau spécialisé pour un équilibreur de charge matériel pour gérer le deuxième serveur. Fondamentalement, le trafic Web (TCP) nécessite un accusé de réception de chaque paquet envoyé / reçu. Donc, si un utilisateur envoie un paquet à votre réseau, il serait dupliqué à la fois sur votre réseau de prod et sur votre réseau fantôme. Les serveurs de chaque réseau répondent, et le paquet du serveur de prod est renvoyé à votre machine qui renvoie un accusé de réception, et ils continuent joyeusement leur conversation. Cependant, si vous supprimez le paquet de votre serveur fantôme, il ne verra pas d'accusé de réception. Ainsi, il essaiera de le renvoyer, et en même temps, ralentira ses vitesses de transmission pour toute l'activité du réseau (c'est ce qu'on appelle le fenêtrage). Il continuera à réessayer de l'envoyer jusqu'à ce qu'il expire, et la session est démolie. Honnêtement, vous ne seriez même pas en mesure de terminer une poignée de main pour établir une connexion en premier lieu.
À propos de la plus proche, vous pourriez transférer le paquet de synchronisation d'origine vers votre serveur miroir, puis définir la passerelle par défaut pour ces boîtes comme un emplacement inexistant. Ensuite, à chaque fois qu'un utilisateur tentait d'établir une connexion, il obtiendrait un vrai serveur sur votre réseau de prod et, à tout le moins, vous enverriez un paquet de synchronisation au réseau fantôme. Bon sang, maintenant tu me demandes comment tu pourrais faire fonctionner ça aussi :)
la source
J'ai pu poser des questions à @adrianco à ce sujet lors d'une rencontre Netflix.
La réponse a été qu'ils ont écrit leur propre outil, qui est fondamentalement un ServletFilter (désolé, terminologie spécifique à Java) qui recrée la demande actuelle et effectue une invocation asynchrone de type «ignorer et oublier» sur un serveur cible.
Les avantages sont les suivants:
L'inconvénient:
la source