Comment est la performance Accurev?

Question

Quelle est la performance dans la version actuelle (4.7) de Accurev ?

• temps de paiement par 100 Mo, par Go?
• l'heure de validation par nombre de fichiers ou de Mo?
• réactivité de l'interface graphique lorsque plus de 100 flux?

Je viens juste d'avoir une démonstration d'Accurev et les flux ressemblent à un moyen léger de modéliser le flux de travail autour du code / des projets. J'ai entendu des gens vanter Accurev pour ses flux et se plaindre de ses performances. Accurev semble avoir travaillé sur la performance, mais j'aimerais obtenir des données réelles pour m'assurer que ce n'est pas un cas de démonstration-fonctionne bien-moins-bien.

Quelqu'un a-t-il des anecdotes sur les performances d'Accurev ou (encore mieux) des données de test?

Answer 1

Je n'ai pas de chiffres mais je peux vous dire où nous avons constaté des problèmes de performances.

Nos versions utilisent généralement des fichiers de 30 à 40 Ko à partir du contrôle de source. Mon espace de travail contient actuellement plus de 66 Ko de fichiers, notamment des fichiers intermédiaires et de sortie de plus de 15 Go. Pour que AccuRev continue de fonctionner correctement, nous utilisons de manière agressive les éléments ignorer . AccuRev ignore donc les fichiers intermédiaires tels que * .obj. Nous utilisons également l'optimisation de l'horodatage . En général, l’exécution d’une mise à jour est rapide, mais la taille du projet est généralement de 5 à 10 personnes. Normalement, seulement une douzaine de fichiers sont supprimés si vous mettez à jour quotidiennement. Même si quelqu'un a apporté des modifications qui ont touché beaucoup de fichiers, la vitesse n'est pas un problème. D'autre part, une population complète de tous les fichiers 30K + est lente. Je n'ai pas le temps depuis que je fais rarement cela et à l'occasion rare que je fais, je dirige la population quand je vais pour déjeuner ou une réunion. Je pense que cela pourrait prendre jusqu'à 10 minutes. En général, les fichiers sources s'abaissent très rapidement, mais nous disposons de gros fichiers binaires, 10 à 20 Mo, qui prennent quelques secondes chacun.

Si les règles d'exclusion et les éléments ignorés ne sont pas correctement configurés, AccuRev peut prendre quelques minutes pour exécuter une mise à jour d'espaces de travail de cette taille. Lorsque j'entends d'autres développeurs se plaindre de la vitesse, je sais que quelque chose est mal configuré et nous le réglons.

Il y a environ un an, l'un des projets a mis à jour boost avec 25 000 fichiers et a également ajouté FireFox au référentiel (oubliez sa taille, mais réduisez-le.) Ils ont également ajouté ICU, écrit de nombreux logiciels et modifié d'innombrables fichiers. En tout je me souviens, il y avait environ 250K + fichiers assis dans un flux. J'ai malheureusement décidé que tout leur code devait être promu à la racine afin que tous les projets puissent être partagés. Cela s'est avéré être un peu au-delà de ce que AccuRev pourrait bien gérer. Ce fut un processus de plusieurs heures permettant de promouvoir tous les changements. Si je me souviens bien, une fois que FireFox a été promu, le reste s'est bien passé - le problème était peut-être une transaction unique contenant plus de 100 000 fichiers?

J'ai récemment mis à jour boost et j'ai donc dû conserver et promouvoir les fichiers de 25 000 $ ou plus. Cela a pris une minute ou deux, mais pas déraisonnable compte tenu du nombre de fichiers et de la taille des fichiers binaires.

En ce qui concerne le nombre de flux, nous avons plus de 800 flux et espaces de travail. La performance ici n'est pas un problème. En général, je trouve qu'il est difficile de naviguer dans le grand nombre de flux. Je lance donc une vue filtrée de mes espaces de travail et des flux qui m'intéressent. Toutefois, lorsque je dois consulter la liste non filtrée pour rechercher des performances optimales, <. / p>

Enfin, le support AccuRev est génial . Nous les appelons la voix dans le ciel. De temps en temps, nous nous tirons une balle dans le pied avec AccuRev et nous ne savons pas comment réparer les choses. Presque toujours, nous avons fait quelque chose de stupide, puis nous avons essayé quelque chose de plus humble pour le réparer. Finalement, nous faisons une demande d'assistance et nous savons maintenant qu'ils nous guident pas à pas vers la justice, que ce soit au téléphone ou lors d'une réunion de travail. Je les ai même contactées pour des choses insignifiantes que je n'ai pas le temps de comprendre, car je passe une journée mouvementée et qui ont bien voulu me guider à travers plutôt que de me dire à RTFM.

Answer 2

Édition 2014: nous pouvons maintenant obtenir des performances acceptables sous X-Windows en utilisant la version commerciale de RealVNC.

Commentaire original: Cette réponse s’applique à n’importe quelle version d’Accurev, pas seulement à la version 4.7. Tout d’abord, les performances de l’interface graphique peuvent être acceptables si vous pouvez utiliser le client Web. Si vous ne pouvez pas utiliser le client Web et si vous voulez des performances d'interface graphique, vous feriez mieux d'utiliser Windows ou de placer tous vos développeurs au même endroit, c'est-à-dire l'emplacement du serveur Accurev. Essayez d'exécuter l'interface graphique sur X-Windows sur un réseau étendu? Oubliez ça: notre expérience compte des dizaines de secondes ou minutes pour des opérations de base de pointage et de clic. C’est sur un réseau WAN assez bon à environ 800 km, avec un temps de réponse quasi optimal. Ce n'est pas un échec d'Accurev, mais de X-Windows, et vous rencontrerez probablement des problèmes similaires avec d'autres applications X sur un réseau étendu. Donc, évitez les bases X si vous le pouvez. Actuellement, nous ne le pouvons pas, et nos utilisateurs de réseau étendu (WAN) sont forcément relégués à la ligne de commande uniquement. Le problème fondamental est que Accurev est centralisé et que vous ne pouvez pas augmenter la vitesse de la lumière. Je pense que vous pouvez contourner le temps d'attente WAN en exécutant Accurev Replication Server, mais cela ne résout pas le problème correctement si vous avez des développeurs distants dans des bureaux pour une seule personne sur un réseau privé virtuel. Il est ironique que les serveurs de réplication transforment quelque peu ce VCS centralisé en une forme de DVCS. Si vous n’avez pas de serveur de réplication, une solution horrible mais relativement pratique consiste à utiliser un outil de synchronisation delta tel que rsync pour synchroniser votre arborescence source entre votre machine locale sur laquelle vous pouvez exécuter l’interface graphique. Windows ou Linux) et la machine sur laquelle vous travaillez (par exemple, une machine UNIX à 1 000 km). Une autre option consiste à utiliser quelque chose comme VNC qui fonctionne mieux sur un réseau WAN que sur X, en se connectant à un bureau virtuel à l'emplacement du serveur Accurev et en utilisant X à partir de là. Sur mon lieu de travail, plusieurs équipes ont eu recours à Mercurial en parallèle et à promouvoir Accurev uniquement lorsque cela est strictement nécessaire. Comme le souligne Stephen Nutt ci-dessus, l'utilisation de l'optimisation de l'horodatage est un autre travail nécessaire. Nous avons également nos administrateurs Accurev (oui, vous devez employer des personnes pour le surveiller) lorsque nous devons inclure un grand nombre de fichiers, même s’ils font partie intégrante de notre produit et DOIVENT être inclus et contrôlés par la version. Tirez vos propres conclusions.