2009-04-09 14 views
7

Tenemos enormes problemas con Visual Studio (2008, si lo que importa) de bloqueo y desaceleración cuando se accede a los proyectos a través de una unidad de red. Puede tomar varios minutos abrir un gran proyecto de sitio web a través de una unidad asignada, y guardar incluso un solo archivo puede demorar un minuto o más.¿Tiene problemas de rendimiento cuando trabaja en proyectos de Visual Studio a través de un recurso compartido de red?

Encendí Wireshark y miré el tráfico. VS, al parecer, solicita cantidades masivas de archivos de la red, hay una enorme cantidad de tráfico SMB. Investigué un poco, y este tráfico parece provenir de dos situaciones.

  1. VS tiene que tener todo en su propio proceso para proporcionar Intellisense.
  2. VS necesita tener toda la fuente con el fin de compilar el proyecto.

Todos los consejos que he leído parecen resumirse en lo mismo: trabaje localmente, no en una máquina remota, luego envíe su código a un servidor de integración a través del control de fuente.

Esto resolvería nuestros problemas (VS es bastante rápido trabajando localmente), pero ¿qué pasa si no puede trabajar localmente? ¿Qué pasa si el proyecto y la infraestructura requerida para ejecutarlo es demasiado grande y complicado para ser replicado en las máquinas individuales de cada uno?

Hemos solucionado este problema un par de veces, y la única forma en que podemos trabajar en estos proyectos es el acceso directo a través de una unidad mapeada. Sin embargo, la lentitud VS y los bloqueos realmente se están convirtiendo en un problema.

Una solución: instalamos VS en el servidor y trabajamos en los proyectos directamente en los servidores a través de RDP. Seriamente.

Por lo tanto, pregunto:

¿Qué hacer a todos los demás? ¿Trabajas a través de la red o reproduces proyectos localmente? Si de forma remota, sufre problemas de rendimiento de VS.

+0

Ni siquiera estoy seguro de cómo se las arreglan para hacer esto con grandes sitios web, los límites de conexiones medio abiertas en las ventanas deben causar problemas con las notificaciones de cambio de archivo que Visual Studio/IIS/uso WebDev. – meandmycode

+0

Desarrolle lo que quiere decir con "proyecto y la infraestructura necesaria para ejecutarlo es demasiado grande y complicado" –

Respuesta

10

, trabajamos localmente y usar SVN para mantener todo nuestro código en el servidor.

Encuentro VS 2008 bastante lento trabajando localmente a veces, así que no me gustaría trabajar en una red compartida.

+0

Esto es lo que terminamos haciendo. Implementamos CruiseControl.net para administrar la integración. – Deane

0

Me encontré con problemas similares cada vez que trabajé (trabajo = cualquier otra cosa, simplemente copie/pegue archivos) en una unidad de red. El problema ocurrió con ZendStudio y Eclipse.

Por qué no usar ningún tipo de control de código fuente?

0

Cuando se trabaja en proyectos basados ​​en Windows Siempre he trabajado a nivel local.

Una vez en una tienda de Unix (AIX IIRC) desarrolladores trabajarían a través de NFS y Entrada/Salida a través de RCS ...

1

No estoy terriblemente sorprendido de que el uso de VS para cargar los proyectos de más de un recurso compartido de red tiene un rendimiento cuestiones. VS (en cualquier idioma) constantemente obtiene información de los archivos del proyecto. Una vez que comience a cargar esto en una red, estará a merced de la conexión de red subyacente. Todos los retrasos y problemas de acceso se traducirán directamente en que VS tenga un problema al cargar los contenidos del archivo.

Aconsejo copiar la solución localmente y usar algún tipo de control de código fuente para sincronizar el proyecto en el recurso compartido.

3

Intentar compilar a través de una red compartida es terriblemente lento usando visual studio. Sus horas de inicio serán malas ya que la base de datos de intellisense se regenera. Cada compilación tiene que pasar por la red varias veces. La vinculación lleva una eternidad.

Si necesita el resultado de su compilación en la red, le recomiendo que haga su compilación localmente y que defina un comando posterior a la compilación para copiar los resultados en su recurso compartido.

Si, como dices, no puedes extraer todo localmente, entonces sugeriría que tu proyecto es demasiado grande y debe dividirse en fragmentos más manejables. Para una aplicación de varios niveles, divídala por niveles e invierte en alguna forma de integración continua (por ejemplo, CruiseControl) para crear automáticamente piezas individuales. De esta forma, puede trabajar localmente en una pieza en particular y extraer las porciones de preconstrucción de CI para las otras piezas de la aplicación.

0

Estoy usando VS2005 en una red compartida y no tengo problemas de rendimiento. Sin embargo, es un servidor nuevo (Windows Server 2008). No tengo ningún otro punto de datos para VS ya que usarlo en el trabajo es relativamente nuevo para mí.

Sin embargo, algunos puntos de datos del uso de Netbeans para proyectos anteriores en una red comparten ... El tiempo de construcción local para mi proyecto fue de 2 minutos en Vista, en una máquina AMD de doble núcleo de doble núcleo. Para un proyecto compartido de red, en un cuadro de Server 2003, fue de 20 minutos. Construir ese mismo proyecto desde una antigua Tablet PC (1GHz, un solo núcleo) ejecutando XP localmente fue de alrededor de 5 minutos. Curiosamente, la Tablet PC podría construir en el cuadro Server 2003 en los mismos 5 minutos.

Para aquellos que preguntan "por qué" en la red. El recurso compartido de red se respalda automáticamente, se archiva, etc. Además, de esa manera puedo ver muy fácilmente los mismos proyectos desde múltiples máquinas sin tener que preocuparme por volver a ingresar al repositorio, etc. Una vez que haya pasado a tener su desarrollador cosas en un dispositivo donde puede acceder desde cualquier lugar/cualquier cosa, ¡nunca más querrá hacer almacenamiento local!

+2

Los repositorios de control de origen también se pueden respaldar automáticamente. Compartir la fuente a través de un recurso compartido de red es algo fuera de la edad de piedra, lo siento. –

+0

@ unforgiven3 Sí, el repositorio también se respalda automáticamente. El propósito del código que reside en el servidor no es evitar un repositorio. Es para hacer que mi "copia local" sea tan resistente como el repositorio. Si pierdo mi máquina a la mitad del día y aún no me he comprometido, simplemente salto en otra máquina en lugar de volver a empezar donde quedó el último compromiso ... –

0

Tengo problemas de rendimiento a través de la red, simplemente no son lo suficientemente buenos.

0

Pensé que era de conocimiento común que la velocidad del disco es uno de los principales factores de "lentitud" cuando se trata de usar VS en Windows. La mayoría de las máquinas de desarrollo que he creado tienen proyectos ubicados en unidades RAID0 de 10k RPM, o al menos una unidad de 10k RPM. E incluso entonces parece lento a veces. Tal como está, supongo, hasta que VS2009/VS2010 lo solucione. :)

1

Si el código es demasiado complicado para instalarlo en la máquina de todos, entonces no lo pongas en la máquina de todos. ¿Todos necesitan tener todo para hacer un trabajo productivo?

1

Tengo 79 proyectos en mi solución con los que trabajo. Varios cientos de miles de líneas de código. Retiro mi fuente todos los días desde TFS y la construyo; es una gran cantidad de código, pero es una solución mucho mejor que tratar de trabajar en un recurso compartido de red.

0

Desde mi experiencia, este retraso cuando se trabaja en una red compartida es 99% debido a Intellisense. Desactívelo y verá.

1

Una situación más legítima de tener el código fuente en un recurso compartido es cuando uno tiene un host que no es de Windows en el que se está ejecutando un (número de) máquina virtual de Windows.

que tienen esta situación exacta donde mi máquina de escritorio (la anfitrión) se está ejecutando Debian y que utiliza VMware para ejecutar varias máquinas virtuales de Windows (los huéspedes), incluyendo uno que ha instalado Visual Studio para que pueda apuntar al sistema operativo Windows. Tener el código fuente en un recurso compartido Samba en la máquina host tiene de la siguiente pro:

  • La fuente no se duplica, lo que no hay manera de confundir a diferentes copias mientras se trabaja en varias máquinas virtuales al mismo tiempo.
  • Tengo control total sobre la fuente de mi sistema operativo preferido.
  • Puedo encender y apagar cualquiera de las máquinas virtuales, o retrotraer a una instantánea, sin el riesgo de perder los cambios.
  • I puede construir (etc.) de la fuente de mismo en varias máquinas sin tener que confirmar los cambios antes de la fuente de prueba completamente (motivo: Tengo que usar Subversion < 1,5).

La única problema con esta disposición es que Visual Studio (6,7,8,9) es muy lento.

He montado la partición (en la que se encuentra el recurso compartido) con "relatime" y esto funciona en cuanto a la actividad de disco en el recurso moderado, pero Visual Studio mantiene la tarjeta de red (virtual) ocupada todo el tiempo.

Cualquier solución a esto sería muy apreciada.

0

También he experimentado los problemas de rendimiento mencionados anteriormente. Parece variar de un proyecto a otro, pero encontré una manera de acelerar el rendimiento significativamente para algunos tipos de proyectos.

Siguiendo el consejo en this article hizo un proyecto inutilizable anteriormente en una ubicación de red (llevaría minutos abrir un archivo) realizar casi como un proyecto local. El punto básico es que es necesario conceder FULL TRUST a la ubicación de red:

de conceder permiso a todos sus proyectos en la carpeta de Visual Studio Projects ubicados en la red, siga estos 8 pasos:

Abra Microsoft Configuración de .NET Framework 1.1 (o 2.0) que encontrará en en Herramientas administrativas en el Panel de control.

Expandir Política de seguridad de tiempo de ejecución | Máquina, | Grupos de código | All_Code | LocalIntranet_Zone En el panel derecho, haga clic en Agregar un código de niño Grupo.

En el cuadro de diálogo siguiente, seleccione Crear un nuevo grupo de códigos y complete a Nombre como Visual Studio Projects.

Opcionalmente, proporcionar una descripción para el grupo de códigos. (Usted verá la descripción cuando se hace clic en un grupo de códigos en el árbol de la izquierda, que le ayuda identificar los diversos grupos de código que pueda tener).

En el tipo de condición desplegable, seleccione URL

para el campo URL, escriba algo como esto:

file://YourServer/My Documents/Visual Studio Projects/* 

En Usar conjunto de permisos existente, seleccione FullTrust (es decir, si confianza sus propias aplicaciones. Si no lo hace, elija un conjunto de permisos diferente o cree uno nuevo).

No estoy seguro de por qué esto funciona, pero hizo que un proyecto NET 2.0 previamente inutilizable tuviera un rendimiento significativamente mejor.

Artículo original: http://imar.spaanjaars.com/364/how-do-i-allow-my-visual-studio-net-projects-to-run-from-a-network-location

0

que estaba teniendo el mismo problema. Tengo una copia local de nuestro sistema de compilación, que espera ciertas letras de unidad, y también estaba experimentando lentitud.

que han resuelto el problema mediante la adición de las claves de registro siguientes:

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ DOS dispositivos] "R:" = "\ DosDevices \ D: \ devel \ construir "S:" = "\ DosDevices \ D: \ devel \ src"

Tenga en cuenta que el doble '\' s anteriores son parte del formato de archivo .reg al utilizar regedit uso sencillo '\' en todas partes..

Mis tiempos de construcción se dividieron por 3. :)

Encontré la información en el artículo de wikipedia sobre el comando SUBST.

Cuestiones relacionadas