Visual Studio lento en un recurso compartido por VPN: por qué guardar se vuelve viajes de ida y vuelta

Una solución que se abre en un segundo desde un disco local tarda treinta segundos en abrirse desde un recurso compartido al que se llega por un túnel. El túnel rara vez es la causa por sí solo. Lo que cambia es que las operaciones que eran llamadas locales se convierten en viajes de ida y vuelta sincrónicos, y el editor realiza varios antes de que aparezca la ventana. El mecanismo siguiente explica por qué cada uno es caro y cuáles puede eliminar.

Qué hace el editor mientras un archivo está abierto

Un editor con seguimiento de cambios mantiene una suscripción en cada archivo abierto. Un volumen local sirve esa suscripción desde el sistema de archivos sin red. A través de un recurso compartido la misma función puede degradarse en lecturas repetidas de metadatos, porque el modelo de notificaciones no se comporta igual sobre SMB. Desactivar el seguimiento de cambios es un primer experimento justo, ya que elimina toda una clase de peticiones sin tocar el túnel.

El sistema de proyectos añade tráfico propio. Al cargar una solución se enumeran directorios, se leen archivos de proyecto y puede sondear SDK o paquetes, y cada sondeo es un viaje de ida y vuelta cuando la ruta es remota. Una solución con muchos proyectos multiplica ese recuento, por eso el tiempo de apertura crece más rápido de lo que sugerirían los tamaños de archivo.

Búsquedas del shell que caducan antes de que aparezca el menú

Windows aporta una segunda fuente de bloqueos que nada tiene que ver con el IDE. El Explorador y sus extensiones de shell vuelven a resolver impresoras, unidades asignadas y accesos directos usados antes cada vez que se abre un menú contextual. Cuando esos destinos están en una red a la que el túnel no llega, cada resolución se bloquea hasta que vence un tiempo de espera, y solo entonces se pinta el menú. Por eso un clic derecho puede colgarse segundos mientras el archivo se abre con normalidad.

Elimine las asignaciones muertas y las colas de impresión, o conserve solo las que existen en la red en la que está realmente. El mismo razonamiento cubre todo lo que resuelve una ruta en segundo plano, incluidas las listas de archivos recientes y las carpetas ancladas.

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

Por qué gana una copia de trabajo local

Trabajar directamente en el recurso compartido es la peor configuración para un ciclo de edición, compilación y prueba, porque el editor, el compilador y el cliente de control de versiones leen cada uno esos archivos remotos por separado. Cada uno paga su propio viaje de ida y vuelta, y una compilación paga una vez por archivo. Una copia local con envíos a través del repositorio sustituye una avalancha de pequeños cruces por uno solo intencionado. El enlace no ha mejorado; el número de cruces se ha derrumbado.

Eso es un cambio estructural y no un ejercicio de ajuste, y es exactamente por eso que funciona cuando los ajustes del túnel no lo hacen. También hace obvio el modo de fallo: si la compilación sigue siendo lenta con una copia local, el recurso compartido nunca fue el problema.

Mueva el historial como un solo objeto

Cuando el repositorio mismo debe cruzar el túnel, envíe el historial en un solo objeto en lugar de recorrerlo. Un paquete es un solo archivo y por tanto un solo tránsito, mientras que un checkout que recorre miles de objetos sueltos cuesta miles de cruces. Mercurial y Git admiten ambos esa forma.

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

La revisión base es la parte que hay que acertar, porque decide cuánto historial viaja. Empaquetarlo todo funciona y desperdicia el enlace, mientras que empaquetar desde el último cambio común mueve solo lo que le falta al otro lado.

Mida tres operaciones antes de culpar al ancho de banda

Mida tres cosas por separado: un archivo pequeño abierto, un directorio listado, un guardado completado. Si las tres son lentas en proporción al número de archivos, el coste son los viajes de ida y vuelta. Si una se atasca mientras las otras van bien, sospeche de un tiempo de espera contra un recurso inalcanzable y no del ancho de banda. Anote en qué red estaba la máquina en cada ejecución, porque un portátil que se reconecta a otro perfil puede cambiar la respuesta entre intentos.

Luego repita las mismas tres contra una copia local del proyecto. La diferencia es el precio del recurso compartido, y es el número que hay que citar cuando alguien propone un enlace más rápido como solución.