2010-11-10 9 views
11

Me he dado cuenta de que la clonación de repos a través de ssh es mucho más lenta que a través de http independientemente de si es de mis propios servidores o BitBucket. Mucho en mi caso equivale a 10 segundos desde http vs. más de 2 minutos con ssh en el mismo repositorio BitBucket.Mercurial: rendimiento de acceso a través de ssh y http

Estoy usando Mercurial en Windows (TortoiseHg 1.5, Mercurial 1.7). Ambas pruebas se realizaron tanto desde GUI como desde CLI.

¿Es un "problema" común o estoy haciendo algo mal?

Respuesta

3

¿Ha activado la compresión ssh en su cliente ssh? Está activado de forma predeterminada en HTTP, pero está desactivado de manera predeterminada en ssh, es una configuración que tiene los controles ssh y no mercurial.

http://confluence.atlassian.com/display/BITBUCKET/Using+SSH+to+Access+your+Bitbucket+Repository#UsingSSHtoAccessyourBitbucketRepository-EnablingCompression

acceso ssh Por lo general, es más rápido que Mercurial http - que es para mí de todos modos.

Encuentro que en una LAN las cosas son más rápidas sin compresión (la compresión toma más tiempo que xfer) y en una WAN es al revés.

+0

Sí, he agregado -C flag hace mucho tiempo y cuando lo hago "clonar" lo veo en la línea de comandos completa – zerkms

+0

, supongo que no se darán más respuestas. así que verifico esto. – zerkms

2

He visto lo mismo.

Al principio, tuve un problema con ssh RHEL4/RHEL5, que prohibía la negociación de la negociación, pero eso está solucionado ahora (ajustes de configuración). Lamentablemente, todavía veo un factor de ~ 3 en la clonación de un repositorio (http vs. ssh).

He usado "ssh = ssh -C -v" para ver la relación de compresión.

Estoy usando Linux, y veo esto al clonar un repo grande (180M +) - en una WAN (Europa < -> India/Asia).

+0

Gracias por la respuesta. Al menos no estoy solo con ese problema ;-) – zerkms

Cuestiones relacionadas