Atlassian Crucible très lent sur un grand référentiel

Mon entreprise exécute un essai d'Atlassian Crucible depuis quelques mois maintenant. Pour les référentiels où il fonctionne correctement, les utilisateurs ont donné des commentaires très positifs sur l'outil. Le problème que j'ai, c'est que nous avons plusieurs projets différents, chacun avec son propre référentiel, et certains de ces référentiels sont très grands. Un référentiel en particulier a un grand nombre de branches et probablement environ 9 000 fichiers par branche. Parcourir ce référentiel dans Crucible est extrêmement lent.

Crucible s'exécute sur une machine virtuelle CentOS. La machine virtuelle a 4 Go de RAM, et j'ai fixé le maximum de Crucible à 3 Go, dont elle utilise actuellement 2 Go. J'ai soulevé cette question dans un ticket de support avec Atlassian, et ils ont suggéré ce qui suit:

En particulier parce que vous avez un référentiel SVN assez volumineux, vous constaterez probablement que Fisheye créera un grand fichier d'index sur le disque. Pour aider à améliorer les performances, vous pouvez essayer plusieurs choses:

• Augmenter la mémoire disponible disponible pour Fisheye.
• Migration vers une base de données externe .
• Exclure les fichiers et répertoires de votre index qui ne sont pas nécessaires .

J'ai essayé toutes ces choses dans une certaine mesure, mais jusqu'à présent, aucune n'a beaucoup aidé. J'utilisais à l'origine Crucible sur une boîte Windows avec 2 Go de RAM en utilisant la base de données HSQL intégrée. Le passage à MySQL sur CentOS a vu une augmentation des performances de certains référentiels et a rendu Crucible beaucoup plus stable, mais ne semble pas beaucoup aider avec notre plus grand référentiel. Il n'y a que tant de fichiers / branches que je peux exclure de l'indexation tout en conservant l'utilité de l'outil.

Cela étant, quelqu'un a-t-il des conseils sur la façon d'accélérer Crucible sur les grands référentiels, sans investir dans du matériel incroyablement puissant?

Merci!

Edit: Pour clarifier les choses, puisque je ne l' ai pas mentionné explicitement ci - dessus, je suis utilise fisheye.

Edit 2: Depuis que j'ai publié ceci, les performances se sont quelque peu améliorées avec les nouvelles versions de Crucible, mais ce n'est toujours pas génial du tout. Il semble que ce problème affecte de nombreux utilisateurs , y compris certains avec un matériel beaucoup plus puissant que celui que nous utilisons. Ainsi, je ne pense pas que ce soit un problème matériel, mais plutôt un problème d'inefficacité inhérente à Crucible. Atlassian est conscient du problème et inclura de nouvelles améliorations de performances dans les futures versions, donc j'espère que ces changements résoudront nos problèmes.

Édition 3: j'avais oublié depuis combien de temps j'avais posé cette question, donc dans mon édition précédente, j'ai négligé de mentionner que notre situation matérielle a également changé depuis qu'elle a été posée à l'origine. Nous exécutons maintenant Crucible sur un serveur physique dédié, toujours en utilisant CentOS. Le matériel est encore modeste (4 Go de RAM, processeur quad core et deux disques de 500 Go en RAID 1 avec sauvegarde externe), mais nous avons constaté une légère augmentation des performances lorsque nous nous sommes éloignés de la machine virtuelle.

Étant donné que la migration vers MySQL a fait une différence notable pour certains référentiels, envisagez de régler la base de données pour de nouvelles améliorations. La modification de certaines my.cnfvaleurs par défaut peut faire une énorme différence. Voir Bases de l'optimisation des performances InnoDB pour plus d'informations. Vérifiez également les requêtes lentes en activant le journal des requêtes lentes et ajoutez des index le cas échéant.

Ma prochaine supposition serait la vitesse du réseau: votre instance Crucible est-elle sur le même réseau local câblé que vos référentiels SVN? Vous pouvez également essayer de tester Crucible sur la même machine que votre référentiel principal si possible pour éliminer la latence du réseau en tant que coupable.

Et je sais que cela peut être difficile en fonction de votre environnement de travail, mais l'exécution de Crucible dans une machine virtuelle n'aide probablement pas les choses; Atlassian en prend note sur leur très brève page Meilleures pratiques pour la configuration du creuset . Je suis sûr que vous l'avez déjà rencontré, mais je mentionnerai également la page Tuning FishEye pour les autres lecteurs.

J'ai également des problèmes de performances pour les grands projets, mais j'attribue beaucoup de lenteur à l'interface Web lourde de Crucible. Cela est particulièrement vrai après avoir cliqué un peu (les pages précédemment consultées dans une critique restent dans la fenêtre du navigateur, même lorsqu'elles sont cachées). Nos développeurs ont remarqué une légère augmentation de la vitesse en passant à Google Chrome. Consultez également le connecteur IDE Atlassian si un plug-in compatible existe pour votre environnement de développement. Le connecteur IDE Eclipse a eu ses propres problèmes la dernière fois que je l'ai utilisé (il y a plusieurs mois), mais il pouvait au moins gérer de grands ensembles de fichiers sans raccrocher.

Selon les pratiques de développement de votre entreprise, vous pouvez arrêter d'analyser un grand nombre de branches de code (en supposant que plusieurs d'entre elles ne sont plus actives) et désactiver les référentiels pour les projets terminés / morts jusqu'à ce qu'ils soient nécessaires. Mon entreprise utilise de très petites équipes sur un grand nombre de projets, donc la plupart du temps nous travaillons principalement sur trunk, faisant des succursales l'exception; nous ajoutons donc explicitement des branches à scanner au lieu d'inclure toutes les branches par défaut. Assurez-vous également que vous ne numérisez pas accidentellement les balises.

Comment est votre utilisation du processeur sur la boîte Crucible? Si vous utilisez SVN derrière Apache HTTPD, examinez combien de connexions sont consommées par Crucible pendant une analyse de grand référentiel. En dehors de cela, je ne sais pas quoi d'autre vous pourriez regarder (peut-être la vitesse du disque? Fréquence de scan du référentiel?), Mais j'espère que les conseils ci-dessus vous aideront un peu.

> 4 G de RAM n'est pas un matériel "incroyablement puissant". En supposant que vous avez 25 utilisateurs et que vous utilisez Fisheye (que vous mentionnez), vous dépensez 4400 $ uniquement pour le logiciel. 4 000 $ chez Dell pourraient vous acheter un serveur avec 48 Go de RAM.

De plus, utilisez-vous une JVM 64 bits? Les documents suggèrent que vous verrez une meilleure empreinte mémoire (comme dans, moins) sur une JVM 32 bits.

Bien que je n'aie pas essayé cela moi-même, je ressens exactement les mêmes symptômes que vous.

J'envisage actuellement de désactiver les informations de diff stockées pour les référentiels incriminés. J'ai posé la question sur le site de questions-réponses d' Atlassian et j'ai obtenu des conseils prometteurs.

Mon problème est le même - l'indexation n'est pas le problème, c'est une énorme empreinte de disque s'exécutant sur une matrice de disques peu performante dans une machine virtuelle. Comme je ne peux pas actuellement mettre à niveau le disque, je dois trouver un autre moyen de le contourner. Le répondeur dans mon article ci-dessus dit que la suppression des informations de différence réduira l'empreinte du disque au détriment de la possibilité de rechercher des lignes ajoutées / supprimées . Bien qu'il suggère également que cela n'affectera pas la vitesse de navigation dans les fichiers à longue histoire.

Si quelqu'un d'autre voit cela et peut signaler un succès / échec avec ce commutateur, veuillez commenter ici.

Oh, et je lance 2.7.13 avec les mêmes problèmes de performances.