Si verificano problemi di prestazioni quando si lavora a progetti di Visual Studio tramite una condivisione di rete?

Question

Abbiamo enormi problemi con Visual Studio (2008, se questo è importante) di blocco e di rallentamento durante l'accesso ai progetti su un'unità di rete. Possono essere necessari diversi minuti per aprire un progetto di sito Web di grandi dimensioni tramite un'unità mappata e il salvataggio di un singolo file può richiedere un minuto o più.

Ho sparato a Wireshark e ho osservato il traffico. VS, a quanto pare, richiede enormi quantità di file dalla rete - c'è un'enorme quantità di traffico SMB. Ho fatto qualche ricerca e questo traffico sembra derivare da due situazioni.

1. VS deve avere tutto nel proprio processo per fornire Intellisense.
2. VS deve disporre di tutta la sorgente per compilare il progetto.

Tutti i consigli che ho letto sembrano riassumersi nella stessa cosa: lavorare localmente, non su una macchina remota, quindi inviare il codice a un server di integrazione tramite il controllo del codice sorgente.

Questo sicuramente risolverebbe i nostri problemi (VS è abbastanza veloce lavorando localmente), ma cosa succede se non si può localmente? Cosa succede se il progetto e l'infrastruttura necessari per eseguirlo sono troppo grandi e complicati per essere replicati sulle singole macchine di tutti?

Abbiamo risolto questo problema un paio di volte e l'unico modo in cui possiamo capire di lavorare su questi progetti è l'accesso diretto tramite un'unità mappata. Tuttavia, la lentezza e il blocco di VS stanno davvero diventando un problema.

Una soluzione: abbiamo installato VS sul server e lavorato sui progetti direttamente sui server tramite RDP. Sul serio.

Quindi, chiedo:

Cosa fa tutti gli altri fare? Lavori tramite la rete o esegui la replica dei progetti localmente? Se remoto, soffri di problemi di prestazioni VS.

Answer 1

Lavoriamo localmente e usiamo SVN per mantenere tutto il nostro codice sul server.

Trovo che VS 2008 lavori piuttosto lentamente a livello locale, quindi non mi piacerebbe lavorare su una condivisione di rete.

Answer 2

Ho riscontrato problemi simili ogni volta che ho lavorato (lavoro = qualsiasi altra cosa, semplicemente copia/incolla file) su un'unità di rete. Il problema si è verificato con ZendStudio ed Eclipse.

Perché non utilizzare alcun tipo di controllo sorgente?

Answer 3

Quando si lavora su progetti basati su Windows, ho sempre lavorato localmente.

Una volta in un negozio di Unix (AIX IIRC) gli sviluppatori avrebbero funzionato via NFS mount e checkin/checkout tramite RCS ...

Answer 4

Io non sono terribilmente sorpreso che utilizzando VS per caricare progetti su una condivisione di rete ha prestazioni problemi. VS (in qualsiasi lingua) riceve costantemente informazioni dai file nel progetto. Una volta che inizi a caricarlo su una rete sei alla mercè della connessione di rete sottostante. Tutti i ritardi e i problemi di accesso si tradurranno direttamente in VS con un problema durante il caricamento del contenuto del file.

Si consiglia di copiare la soluzione localmente e utilizzare una qualche forma di controllo del codice sorgente per sincronizzare il progetto sulla condivisione.

Answer 5

Provare a compilare su una condivisione di rete è terribilmente lento utilizzando Visual Studio. I tuoi orari di inizio saranno negativi dato che il database Intellisense viene rigenerato. Ogni compilazione deve andare oltre la rete più volte. Il collegamento richiede per sempre.

Se è necessario l'output della compilation sulla rete, è consigliabile eseguire la compilazione localmente e definire un comando post-build per copiare i risultati nella condivisione.

Se, come dici tu, non puoi estrarre tutto localmente, suggerirei che il tuo progetto è troppo grande e deve essere suddiviso in blocchi più gestibili. Per un'applicazione multilivello, suddividila per livello e investi in qualche forma di integrazione continua (ad esempio CruiseControl) per creare automaticamente singoli pezzi. In questo modo puoi lavorare localmente su un particolare pezzo e tirare le porzioni pre-compilazione da CI per gli altri pezzi dell'applicazione.

Answer 6

Sto utilizzando VS2005 su una condivisione di rete e non ho problemi di prestazioni. Tuttavia, è un nuovo server (Windows Server 2008). Non ho altri punti dati per VS dal momento che utilizzarlo al lavoro è relativamente nuovo per me.

Tuttavia, alcuni punti dati dall'utilizzo di Netbeans per progetti precedenti su una condivisione di rete ... Il tempo di compilazione locale per il mio progetto era di 2 minuti su Vista, su una macchina AMD a 64 bit dual-core veloce. Per un progetto di condivisione di rete, in una casella Server 2003, erano 20 minuti. Costruire lo stesso progetto da un vecchio Tablet PC (1ghz, single core) con XP localmente era di circa 5 minuti. È interessante notare che il Tablet PC potrebbe costruire sulla casella Server 2003 negli stessi 5 minuti.

Per chi chiede "perché" sulla condivisione di rete. La condivisione di rete viene automaticamente sottoposta a backup, archiviata, ecc. Inoltre, in questo modo posso guardare molto facilmente gli stessi progetti da più macchine senza dovermi preoccupare di tornare nel repository, ecc. Una volta che hai finito con il tuo dev roba su un dispositivo in cui è possibile accedervi da qualsiasi luogo/qualsiasi cosa, non vorrai mai più fare memoria locale!

Answer 7

Ho problemi di prestazioni via rete, non sono ancora abbastanza buoni.

Answer 8

Ho pensato che fosse noto che la velocità del disco è uno dei principali fattori di "lentezza" quando si utilizza VS in Windows. La maggior parte delle macchine di sviluppo che ho creato hanno progetti situati su unità RAID0 10k RPM o almeno una singola unità RPM a 10k. E anche allora a volte sembra lento. Per come è, suppongo, fino a quando VS2009/VS2010 lo risolve? :)

Answer 9

Se il codice è troppo complicato da installare sulla macchina di tutti, non inserirlo nella macchina di tutti. Tutti hanno bisogno di avere tutto per fare lavori produttivi?

Answer 10

Ho 79 progetti nella mia soluzione con cui lavoro. Diverse centinaia di migliaia di righe di codice. Estraggo la mia fonte ogni giorno da TFS e la costruisco; è un sacco di codice, ma è una soluzione molto migliore rispetto al tentativo di lavorare su una condivisione di rete.

Answer 11

Dalla mia esperienza, questo ritardo quando si lavora su una condivisione di rete è del 99% a causa di Intellisense. Disabilitalo e vedrai.

Answer 12

Una situazione più legittima di avere il codice sorgente su una condivisione è quando si dispone di un host non Windows su cui è in esecuzione un (numero di) computer Windows virtuale.

ho questa situazione esatta in cui la mia macchina desktop (il ospite) è in esecuzione Debian e utilizzare VMware per eseguire diverse macchine virtuali Windows (i ospiti), tra cui uno che ha installato Visual Studio in modo che io possa target Windows OS. Avere il codice sorgente in una condivisione di Samba sulla macchina host ha del seguente pro:

• La fonte non sia duplicato, quindi non c'è modo di confondere le copie differenti mentre si lavora su più macchine virtuali contemporaneamente.
• Ho il pieno controllo dell'origine dal mio SO preferito.
• Posso accendere e spegnere qualsiasi macchina virtuale o tornare a un'istantanea, senza il rischio di perdere le modifiche.
• posso costruire (ecc) dalla sorgente stesso su più macchine senza dover impegnare modifiche prima sorgente completamente testato (ragione: devo usare Subversion < 1.5).

L'unico problema con questa configurazione è che Visual Studio (6,7,8,9) è lentissimo.

Ho montato la partizione (su cui giace la condivisione) con "relatime" e funziona fino a quando l'attività del disco nella condivisione è moderata, ma Visual Studio mantiene la scheda di rete (virtuale) occupata tutto il tempo.

Qualsiasi soluzione a questo sarebbe molto apprezzata.

Answer 13

invalidanti Intellisense accelera infatti fino risparmio e di apertura dei file attraverso una condivisione UNC drammaticamente

http://blogs.msdn.com/saraford/archive/2007/12/03/did-you-know-how-to-turn-off-intellisense-by-default.aspx

ma poi di nuovo, come affermato in altri commenti, si potrebbe anche usare un buon editor di testo

Answer 14

Ho anche sperimentato i problemi con le prestazioni di cui sopra. Sembra variare da progetto a progetto, ma ho trovato un modo per velocizzare le prestazioni in modo significativo per alcuni tipi di progetto.

Seguendo il consiglio in this article reso un progetto precedentemente inutilizzabile su un percorso di rete (ci vorranno pochi minuti per aprire un file) eseguire quasi come un progetto locale. La sostanza di base è che è necessario concedere FULL TRUST al percorso di rete:

Per concedere l'autorizzazione per tutti i vostri progetti nella cartella di Visual Studio progetti situati sulla rete, attenersi alla seguente 8 passi:

Aprire Microsoft .NET Framework 1.1 (o 2.0) Configurazione che troverai sotto Strumenti di amministrazione nel Pannello di controllo.

Espandi Criterio di sicurezza runtime | Macchina, | Gruppi di codici | All_Code | LocalIntranet_Zone Nel riquadro di destra, fare clic su Aggiungi un codice figlio Gruppo.

Nella finestra di dialogo che segue, scegliere Crea un nuovo gruppo di codici e immettere un nome come Progetti di Visual Studio.

Facoltativamente, fornire una descrizione per il gruppo di codici. (Vedrai la descrizione di quando fai clic su un gruppo di codici nell'albero a sinistra, aiutandoti a identificare i vari gruppi di codici che potresti avere).

Nel Tipo Condizione discesa, scegliere URL

nel campo URL, digitare qualcosa di simile:

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

In Usa set di autorizzazioni esistente, scegliere FullTrust (vale a dire, se fiducia le tue applicazioni. Se non lo fai, scegli un diverso set di autorizzazioni o creane uno nuovo).

Non sono sicuro del motivo per cui questo funziona, ma ha reso un progetto NET 2.0 in precedenza inutilizzabile molto migliore.

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

Answer 15

ho avuto lo stesso problema. Ho una copia locale del nostro sistema di compilazione, che si aspetta alcune lettere di unità, e anche la lentezza.

ho risolto il problema aggiungendo le seguenti chiavi di registro:

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

Si noti che il doppio "\" di cui sopra fa parte del formato di file .reg. Quando si utilizza regedit utilizzare singolo "\" in tutto.

I tempi di compilazione sono stati divisi per 3. :)

Ho trovato le informazioni nell'articolo di wikipedia sul comando SUBST.