Bonjour,
J'observe des temps de réponse extrêmement longs sur les fonctions d’interfaçage avec mantis.
Il faut par exemple près de 5 minutes pour rattacher une anomalie existante sur mantis à un cas de test squash.
En dehors des temps de réponse tout est OK.
SquashTM V1.17
Mantis V2.15 (environ 5000 issues référencées)
RedHat 6.4
J'ai noté que sur une instance de mantis "bac à sable" avec nettement moins de tickets référencés (environ 300) les temps de réponse sont meilleurs mais sans pour autant être acceptables pour une production (plus de 1 minute)
Any help ?
Temps de réponses squashTM / mantis
Temps de réponses squashTM / mantis
Je constate à peu près la même chose avec TM 1.17.4 et Mantis 1.3.14 comportant 22000 tickets et 360 projets.
Seulement, pour moi la requête n'aboutit pas.
J'ai un retour 400 bad resquest dans l'onglet Console de chrome :
http://localhost:8282/squash/bugtracker ... ojectNames ... etc avec les 358 autres projets ... %5B%5D=PROJET+360 [color=#ff0000]400 (Bad Request)
[/color]
Dans l'onglet Network
Query String Parameters
bugTrackerId: 1
projectNames[]: PROJET 1
...
projectNames[]: PROJET 360
Seulement, pour moi la requête n'aboutit pas.
J'ai un retour 400 bad resquest dans l'onglet Console de chrome :
http://localhost:8282/squash/bugtracker ... ojectNames ... etc avec les 358 autres projets ... %5B%5D=PROJET+360 [color=#ff0000]400 (Bad Request)
[/color]
Dans l'onglet Network
Query String Parameters
bugTrackerId: 1
projectNames[]: PROJET 1
...
projectNames[]: PROJET 360
Temps de réponses squashTM / mantis
Apport d'informations supplémentaires.
OS Win7 et plateforme wamp 3.0.6 x64
J'ai réduit la liste des projets à 1 seul.
Lorsque j'essaie d'ajouter une anomalie connue, mais n'appartenant pas aux projets MANTIS déclarés dans Squash, j'obtiens assez rapidement le message :
"Aucune anomalie appartenant au(x) projet(s) paramétré(s) n'a été trouvée."
J'ai fait un test avec uniquement 30 projets ou même 2 projets, j'obtiens dans les 2 cas les temps suivants :
11 sec pour l'affichage de la fenêtre de saisie
28 sec pour la recherche d'un n° de ticket
16 sec pour son ajout dans la liste des anomalies connues
Soit environ une minute, ce qui est décourageant par les utilisateurs souhaitant bien oeuvrer dans la traçabilité transverse.
Quant à l'erreur 400 Bad request elle est due à une limite de taille de la requête GET,
en réduisant la liste des projets à 219 pour une talle maximum de 7488 octets (avec chrome) elle passe avec sensiblement les mêmes temps.
Pour moi, il existe une problématique d'obligation de déclarer l'ensemble des projets MANTIS ainsi que leurs sous-projets pour pouvoir associer dans SQUASH d'une anomalie déjà connue. Normalement, le lien direct sur le bug_id est suffisant dans toutes les URL stockées.
Que l'on souhaite ajouter dans MANTIS un nouveau bug, il est normal de choisir un projet, par contre pour associer un bug existant, il n'est absolument pas nécessaire de parcourir l'ensemble des projets. Les contrôles Projets MANTIS/Issue ID ne me paraissent pas opportun.
Ainsi, il me semble que les différents écrans pourraient être plus rapides et la requête de recherche serait bien plus véloce.
OS Win7 et plateforme wamp 3.0.6 x64
J'ai réduit la liste des projets à 1 seul.
Lorsque j'essaie d'ajouter une anomalie connue, mais n'appartenant pas aux projets MANTIS déclarés dans Squash, j'obtiens assez rapidement le message :
"Aucune anomalie appartenant au(x) projet(s) paramétré(s) n'a été trouvée."
J'ai fait un test avec uniquement 30 projets ou même 2 projets, j'obtiens dans les 2 cas les temps suivants :
11 sec pour l'affichage de la fenêtre de saisie
28 sec pour la recherche d'un n° de ticket
16 sec pour son ajout dans la liste des anomalies connues
Soit environ une minute, ce qui est décourageant par les utilisateurs souhaitant bien oeuvrer dans la traçabilité transverse.
Quant à l'erreur 400 Bad request elle est due à une limite de taille de la requête GET,
en réduisant la liste des projets à 219 pour une talle maximum de 7488 octets (avec chrome) elle passe avec sensiblement les mêmes temps.
Pour moi, il existe une problématique d'obligation de déclarer l'ensemble des projets MANTIS ainsi que leurs sous-projets pour pouvoir associer dans SQUASH d'une anomalie déjà connue. Normalement, le lien direct sur le bug_id est suffisant dans toutes les URL stockées.
Que l'on souhaite ajouter dans MANTIS un nouveau bug, il est normal de choisir un projet, par contre pour associer un bug existant, il n'est absolument pas nécessaire de parcourir l'ensemble des projets. Les contrôles Projets MANTIS/Issue ID ne me paraissent pas opportun.
Ainsi, il me semble que les différents écrans pourraient être plus rapides et la requête de recherche serait bien plus véloce.
Temps de réponses squashTM / mantis
J'ai créé un ticket dans le Mantis de Squash.
[url=https://ci.squashtest.org/mantis/view.php?id=7729]Ticket 7729[/url]
[url=https://ci.squashtest.org/mantis/view.php?id=7729]Ticket 7729[/url]