Cette option est désactivée pour les Rejeux dans la mesure où les Rejeux ne peuvent pas être édités. 

Après une connexion réussie les variables de session suivantes sont positionnées : UserID, UserLogin, UserGroup. Elles sont peuplées avec l'id utilisateur, le login et l'id groupe... On peut lire leurs valeurs en utilisant respectivement les fonctions CCGetUserID(), CCGetUserLogin(), CCGetUserID().

Les noms des variables de session peuvent différer. Merci de les vérifier dans les Paramètres du Projet : Sécurité -> Avancé -> Variables de session.
 

Dans l'exemple, il n'y a pas de différence. La distribution des utilisateurs se fera de la même manière. Pour rappel, le Poids (Weight) détermine le pourcentage approximatif d'utilisateurs qui exécuteront ce Cas-Test pendant le test de charge.
Pour avoir par exemple une distribution des VU : 80% - 20% il suffit de rentrer dans le champs Weight : 80 et 20.
Ce champ n'est pas limité aux pourcentages pour 2 raisons :
1 - Cela nécessiterait d'effectuer une validation supplémentaire... par exemple quand les pourcentages n'atteignent pas 100%...
2 - Si vous voulez que le Cas-Test A ait deux fois plus d'utilisateurs que le Cas-Test B, qui lui-même a deux fois plus d'utilisateurs que le Cas-Test C, alors il vous suffit de rentrer 4, 2 et 1 dans le champ Poids et Web Performance Suite fait le calcul pour vous... au lieu d'avoir à faire un calcul complexe et de renseigner 57,14%, 28,57% et 14,28%. 

Dans l'exemple, il n'y a pas de différence. La distribution des utilisateurs se fera de la même manière. Pour rappel, le Poids (Weight) détermine le pourcentage approximatif d'utilisateurs qui exécuteront ce Cas-Test pendant le test de charge.

Pour avoir par exemple une distribution des VU : 80% - 20% il suffit de rentrer dans le champs Poids : 80 et 20.

Ce champ n'est pas limité aux pourcentages pour 2 raisons :
1 - Cela nécessiterait d'effectuer une validation supplémentaire... par exemple quand les pourcentages n'atteignent pas 100%...
2 - Si vous voulez que le Cas-Test A ait deux fois plus d'utilisateurs que le Cas-Test B, qui lui-même a deux fois plus d'utilisateurs que le Cas-Test C, alors il vous suffit de rentrer 4, 2 et 1 dans le champ Poids et Web Performance Suite fait le calcul pour vous... au lieu d'avoir à faire un calcul complexe et de renseigner 57,14%, 28,57% et 14,28%. 

La syntaxe à utiliser est la suivante :

nettracker admin -add <new_profile_name> -template data/<existingprofile>/<existingprofile>.cfg

Exemple : Je veux créer le profil kapitecnew à partir du profil kapitec

nettracker admin -add kapitecnew -template data/kapitec/kapitec.cfg

Remarques :

1 - En ligne de commande on utilise toujours le nom court du profil

2 - On veille à se positionner dans le répertoire d'installation de NetInsight, qui par défaut est /Program Files/NetInsight/

3 - Les rapports personnalisés (ils comportent le préfixe custom) devront être copiés manuellement dans le répertoire data du nouveau profil 

On peut effectivement rencontrer cette situation quand l'utilisation UC et/ou mémoire du moteur est trop élevée... Veuillez vérifier l'utilisation du moteur dans la vue Moteurs du Contrôleur.
Pour les moteurs de charge actifs prêts ou participant activement à un test de charge, plusieurs informations sont disponibles dans la Vue Moteurs dont :

% UC - L'utilisation UC de l'ordinateur du moteur, où 100% a tous les cycles de la machine en utilisation. A noter que sur UNIX cette valeur peut être sérieusement affectée par les processus en arrière-plan qui sont bloqués, donc même si un processus ne prend pas de temps UC (s'il est en attente ou autre), la charge sera supérieure. Utilisez "ps", "top" ou tout autre programme pour trouver et arrêter les processus en arrière-plan qui peuvent augmenter la charge système, ceci afin de faire en sorte que toute la puissance de l'ordinateur soit dédiée au test de performance. Vous noterez qu'il y a un décalage dans l'obtention de l'information du système d'exploitation, aussi la valeur ne sera pas exactement la même que celle affichée par d'autres utilitaires.

% Mémoire - La quantité de mémoire allouée aux buffers internes qui est réellement utilisée. Ce nombre n'a aucun lien avec une information spécifique du système d'exploitation que vous pourriez voir en utilisant un utilitaire tel que le Gestionnaire de Tâches Windows. Cette valeur va monter et descendre pendant le test de performance et pourra occasionnellement atteindre les valeurs bas ou manque de mémoire. Elle remontera lentement vers les 80% lors de l'utilisation d'un nombre important d'Utilisateurs Virtuels ou lors de l'exécution d'un test de performance sur une longue période de temps. Si le programme manque véritablement de mémoire, vous verrez alors cette valeur passer rapidement les 90% toutes les 30 secondes ou presque. Lorsque cela se produit, alors plus aucun autre utilisateur n'est ajouté au moteur de sorte à éviter au programme de manquer de mémoire et donc de générer des résultats de test corrompus.  

La touche F8 du clavier : publication d'une page
Les touches Ctrl+F8 : publication rapide de page

La touche F8 génère et publie tous les fichiers page, les fichiers en relation avec la page et les fichiers communs avec le code du projet.

Quant à la publication rapide (touches Ctrl+F8), elle publie uniquement les fichiers pages.  

Pour que le contrôle Navigateur soit toujours visible, il vous faut créer un événement Before Show pour le Navigateur et y mettre ce code
$form->Navigator1->Visible = true; 

CodeCharge Studio n'écrase pas les blocs de code personnalisé... il est donc sûr de mettre le code dans le fichier Common.php. 

Le fait que l'authentification à l'application se fasse via une applet Java, et que cette applet communique avec le serveur en utilisant des objets Java sérialisés (SJOs), pose un problème. Les possibilités de personnaliser ce comportement s'en trouvent sérieusement limitées. Le format des SJOs est un format difficilement lisible, et Web Performance Load Tester ne reconnaît pas ce qui se trouve dans ces objets; il peut seulement les envoyer tels qu'enregistrés. Si les SJOs contiennent des identifiants de session dynamiques, alors le Rejeu correct du Cas-Test sera impossible. Si l'authentification passe par des SJOs, alors la configuration sera difficile. Si d'autres données doivent être changées dynamiquement (par exemple changement de données saisies par l'utilisateur dans l'applet), alors cela accroîtera davantage le niveau de difficulté... et il n'y a pas de garantie de résultat...

Dans la plupart des cas, l'approche consiste à paramétrer tous les SJOs. Cela signifie que chacune des variations du Cas-Test devra être enregistrée et les SJOs sauvegardés. Ils devront alors être ajoutés à un Jeu de Données et la fonctionnalité de Téléchargement de Fichier vers le serveur devra être utilisée pour les importer dans Load Tester pour les utiliser avec les Jeux de Données correspondants. Ensuite chaque requête doit être configurée pour utiliser le SJO approprié à partir d'un Jeu de Données au lieu d'une valeur enregistrée.