JIRA 5.2 pour les administrateurs


Publié par
Nathan CHANTRENNE

26 novembre 2012

Nous avons mentionné dans un article précédent les fonctionnalités offertes par la nouvelle version de JIRA. Aujourd’hui nous allons nous pencher plus précisément vers les améliorations d’administration système. Les performances ont longtemps été une des faiblesses de JIRA pour les instances à forte volumétrie. Atlassian essaye maintenant de prouver que ce temps est révolu ! JIRA 5.1 apportait déjà une amélioration des temps de réponse pouvant aller jusqu’à 40%, repoussant ainsi la limite du nombre de demande par instance de 200 000 demandes à 500 000. Maintenant que ce problème est résolu, Atlassian met à disposition de ses clients un certain nombre d’outils permettant de faciliter le travail des administrateurs systèmes de JIRA.

Ré-indexation

La ré-indexation dans JIRA était jusqu’alors un problème. Impossible de réindexer une instance en pleine journée ; celle-ci était alors inaccessible pendant plusieurs minutes (ou parfois plusieurs heures !), ce qui était difficilement acceptable. Or, à chaque modification du paramétrage de JIRA, une ré-indexation est requise par le système ! Voilà une belle contradiction… La version 5.2 de JIRA remédie à ce paradoxe en proposant une ré-indexation en tâche de fond (l’ancien mode est toujours disponible).

Ce processus est plus lent mais permet tout de même aux utilisateurs de naviguer sur leur outil favori. Nous recommandons tout de même d’exécuter cette opération sur un créneau où JIRA est assez peu utilisé afin d’éviter une surcharge de consommation de la mémoire sur le serveur (les OutOfMemoryError guettent toujours !).

Analyse des logs

Des logs d’accès http (access logs) sont présents sur JIRA depuis bien longtemps. Ils permettent de tracer l’ensemble des requêtes effectuées sur votre instance ainsi que leur temps de traitement. L’ennui est que l’on ne disposait d’aucun moyen simple pour les analyser, il était nécessaire d’en extraire soi-même le contenu, ce qui n’était pas chose facile. Atlassian met maintenant entre nos mains un outil d’analyse de ces access logs (voir ici) tout justement nommé « HTTP requests log analyser ». Ce petit outil va vous permettre de catégoriser l’ensemble de vos requêtes et d’en tirer des statistiques intéressantes. A partir d’un fichier de log, trois fichiers vous sont délivrés :

  • Un fichier .wiki (à insérer dans JIRA ou Confluence) qui affiche la répartition des requêtes sur votre instance JIRA par catégorie, celui-ci vous permettra de savoir où vos utilisateurs passent le plus de temps. Souvent, les gadgets effectuent le plus de requête. Astuce : sensibilisez donc vos utilisateurs à utiliser un nombre raisonnable de gadget sur leurs tableaux de bord afin d’améliorer les performances pour tous les utilisateurs (c’est d’autant plus vrai si un lourd tableau de bord est visible dès la page d’accueil qui une des plus souvent accédée).
  • Un fichier .html qui affiche un graphique des requêtes passées en fonction du temps, intéressant pour connaître vos pics d’utilisation dans la journée.
  • Un fichier .txt qui référence les requêtes non reconnues, typiquement celles de plugins que vous auriez développés.

Champs personnalisés

On constate souvent des effets néfastes sur les performances dans des instances contenant de nombreux champs personnalisés. Atlassian avait d’ailleurs fixé une limite (arbitraire) à 300 champs personnalisés par instance. Afin de confirmer ses dires, ils ont effectué des tests de performance. Les résultats sont visibles ici. Le constat est le suivant :

  • On détecte une forte dégradation des performances au-delà de 600 champs personnalisés avec un contexte global (pour toutes les demandes).
  • En utilisant les contextes de champs personnalisés par projet, les performances de l’application sont bien meilleures qu’en utilisant le masquage des champs avec les configurations de champs.

Bien qu’il soit techniquement envisageable de disposer de 600 champs personnalisés sur une instance, cela devient vite un calvaire à maintenir pour vos chers administrateurs. Nous vous conseillons de rester bien en deçà de cette limite, en se posant les bonnes questions à chaque fois qu’un nouveau besoin se présente : ce nouveau champ est-il vraiment indispensable pour ce processus ? Puis-je réutiliser un champ existant en spécifiant éventuellement un nouveau contexte d’utilisation ?

Pour finir

JIRA 5.2 est la première version de l’outil à supporter les dernières versions de Java (1.7) et de Tomcat (7.0), profitez éventuellement de votre montée de version pour migrer vers ce nouvel environnement.