2009-10-26 15 views
5

¿Cómo es el rendimiento en la versión actual (4.7) de Accurev?¿Cómo es el rendimiento Accurev?

  • Tiempo de pago por 100mb, por gb?
  • tiempo para confirmar por # de archivos o mb?
  • capacidad de respuesta de la interfaz gráfica de usuario cuando más de 100 secuencias?

Acabo de tener una demostración de Accurev, y las secuencias se ven como una forma ligera de modelar el flujo de trabajo alrededor de código/proyectos. Escuché a personas elogiando a Accurev por las transmisiones de fondo y quejándose del rendimiento. Accurev parece haber trabajado en el rendimiento, pero me gustaría obtener algunos datos del mundo real para asegurarme de que no se trate de demos, bueno, funciona menos bien.

¿Alguien tiene anécdotas de rendimiento Accurev o (incluso mejor) datos de las pruebas?

+0

Respuesta anecdótica: Lento. No lo use a menos que sea necesario. La GUI es casi inutilizable. Esto es solo anecdótico, no tengo ningún número imprescindible para respaldar lo que estoy diciendo. – Martin

+0

Acabo de migrar un proyecto de Perforce a la última versión de Accurev 6.2.3 ?, y muchas de las historias de terror que había escuchado aún no se han manifestado de ninguna manera que yo pudiera decir, PERO la GUI es increíblemente lenta y yo no No recomiendo hacer movimientos sin conexión. Me gusta que no tenga que verificar las cosas, pero hay un costo de rendimiento con eso. El problema más importante es cualquier operación en la GUI, incluido el hecho de que hacer clic en un archivo lleva mucho tiempo en comparación con P4. Sugiero aprender la CLI. – Novaterata

Respuesta

8

No tengo ningún número, pero puedo decirle dónde hemos notado problemas de rendimiento.

Nuestras versiones usualmente usan archivos de 30-40K del control de fuente. Actualmente, en mi espacio de trabajo hay más de 66K archivos, incluidos los archivos intermedios y de salida, de más de 15 GB. Para que AccuRev funcione de manera responsable, utilizamos agresivamente los elementos de ignorar para que AccuRev ignore cualquier archivo intermedio como * .obj. Además, utilizamos la optimización del sello de tiempo . En general, ejecutar una actualización es rápido, pero el tamaño del proyecto suele ser de 5 a 10 personas, por lo que normalmente solo descienden un par de docenas de archivos si actualiza diariamente. Incluso si alguien hizo cambios que tocaron muchos archivos, la velocidad no es un problema. Por otro lado, un llenado completo de todos los 30K + archivos es lento. No tengo tiempo, ya que rara vez hago esto y en la rara ocasión que lo hago, corro la población cuando voy a almorzar o a una reunión. Supongo que podría ser tanto como 10 minutos. En general, los archivos de origen descienden muy rápido, pero tenemos algunos archivos binarios grandes, 10-20MB, que demoran un par de segundos cada uno.

Si las reglas de exclusión y los elementos de ignorar no están configurados correctamente, AccuRev puede tardar unos minutos en ejecutar una actualización para espacios de trabajo de este tamaño. Cuando me entero de que otros desarrolladores se quejan de la velocidad, sé que algo está mal configurado y lo solucionamos.

Hace aproximadamente un año, uno de los proyectos actualizó el impulso con archivos de 25K + y también agregó FireFox al repositorio (se olvidó el tamaño pero hizo que el impulso parezca pequeño). También agregaron ICU, escribieron una gran cantidad de software y modificaron innumerables archivos . En total, recuerdo que había aproximadamente 250K + archivos sentados en una secuencia. Lamentablemente, decidí que todos sus buenos códigos deberían promoverse a la raíz para que todos los proyectos pudieran compartirlos. Esto resultó ser un poco más allá de lo que AccuRev podía manejar bien. Fue un proceso de varias horas para promocionar todos los cambios. Como recuerdo, una vez que se promocionó Firefox, el resto se desarrolló sin problemas, tal vez una sola transacción con más de 100 mil archivos fue el problema.

Recientemente actualicé boost y tuve que mantener y promocionar archivos de 25K +. Tardó uno o dos minutos, pero no es irrazonable teniendo en cuenta la cantidad de archivos y el tamaño de los archivos binarios.

En cuanto al número de transmisiones, tenemos más de 800 transmisiones y espacios de trabajo. El rendimiento aquí no es un problema. En general, me resulta difícil navegar por la gran cantidad de secuencias, por lo que ejecuto una vista filtrada de solo mis espacios de trabajo y las secuencias correctas que me interesan. Sin embargo, cuando necesito ver la lista no filtrada para encontrar algo, el rendimiento está bien.

Como nota final, el soporte AccuRev es fabuloso - los llamamos la voz en el cielo. De vez en cuando nos disparamos en el pie usando AccuRev y terminamos sin idea de cómo arreglar las cosas. Casi siempre hicimos algo tonto y luego intentamos algo más tonto para arreglarlo. Eventualmente, hacemos una solicitud de soporte y lo siguiente que sabemos es que nos guían a través de los pasos hacia la rectitud, ya sea por teléfono o en una reunión informativa. Incluso los contacté por cosas triviales que simplemente no tengo tiempo para descubrir ya que estoy teniendo un día agitado y amablemente me guiaron en lugar de decirme a RTFM.

+0

Un poco fuera de tema, pero ¿es posible excluir archivos y carpetas específicos directamente en la interfaz de usuario ahora, para que AccuRev ignore estos archivos (como obj, etc.)? La última vez que utilicé AccuRev (mediados de 2008), tuve que configurar una variable de entorno global en la que enumeré todos los archivos que quería que AccuRev ignorara, lo cual era un problema. – Nitramk

+0

Estamos usando 4.7 y con eso usted todavía necesita establecer una variable de entorno. Hay una versión más nueva disponible que todavía tenemos que actualizar, por lo que puede haber cambiado, pero sospecho que no. –

+0

Puede usar archivos .acignore por directorio, al menos de esa manera viajan con el código pero no son recursivos. –

0

Edición 2014: ahora podemos obtener un rendimiento aceptable de X-Windows utilizando la versión comercial de RealVNC.

Comentario original: Esta respuesta se aplica a cualquier versión de Accurev, no solo a 4.7. En primer lugar, el rendimiento de la GUI podría estar bien si puede usar el cliente web. Si no puede usar el cliente web y desea el rendimiento de la GUI, será mejor que use Windows o que todos sus desarrolladores estén en un solo lugar, es decir, donde se encuentra el servidor de Accurev. ¿Intenta ejecutar la GUI en X-Windows a través de una WAN? Olvídalo: nuestra experiencia ha sido de decenas de segundos o minutos para operaciones básicas de apuntar y hacer clic. Esto es a través de una WAN bastante buena a unas 800 millas de distancia, con un tiempo de ping casi óptimo. Esto no es un fallo de Accurev, sino de X-Windows, y es probable que tenga problemas similares con otras aplicaciones X a través de una WAN. Así que evita la X básica si puedes. Actualmente no podemos, y nuestros usuarios WAN son relegados por la fuerza a la línea de comandos solamente. El problema básico es que Accurev está centralizado y no puede aumentar la velocidad de la luz. Creo que puede evitar la latencia WAN ejecutando Accurev Replication Servers, pero eso aún no soluciona el problema adecuadamente si tiene desarrolladores remotos en oficinas de una sola persona a través de VPN. Es irónico que los servidores de replicación de alguna manera conviertan este VCS centralizado en una forma de DVCS. Si no tiene servidores de replicación, un trabajo horrible pero algo viable es usar una herramienta de sincronización delta como rsync para sincronizar su árbol fuente entre su máquina local donde puede ejecutar la GUI (es decir, la GUI ejecutándose directamente en su Portátil con Windows o Linux) y la máquina en la que realmente está trabajando (p. Ej., La máquina UNIX a 1.000 millas de distancia). Otra opción es usar algo como VNC, que funciona mejor en una WAN que X, conectarse a un escritorio virtual en la ubicación del servidor Accurev y usar X desde allí. En mi lugar de trabajo, más de un equipo ha recurrido a utilizar Mercurial por un lado y promocionar a Accurev solo cuando es estrictamente necesario. Como señala Stephen Nutt más arriba, otro trabajo necesario es utilizar la optimización del sello de tiempo e ignorarlo. También tenemos nuestros administradores de Accurev (sí, requiere que emplee a personas para cuidarlos) se quejan cuando necesitamos incluir una gran cantidad de archivos, a pesar de que forman una parte central de nuestro producto y DEBEN incluirse y controlarse las versiones. Saca tus propias conclusiones.

Cuestiones relacionadas