2012-05-31 13 views
9

Attualmente la mia azienda utilizza TortoiseSVN 1.6.16 a 32 bit su Windows XP per connettersi tramite HTTPS a VisualSVN-Server 2.1.19 in esecuzione su un server Windows 2003 residente nella stessa rete (nessun proxy). Utilizziamo un certificato autofirmato e l'autenticazione Kerberos utilizzando le credenziali di Windows (suppongo che questa sia una funzionalità specifica di VisualSVN). In questa configurazione, tutto funziona dandy.Subversion insopportabilmente lento su Windows 7

Quando la mia azienda ha deciso di passare a Windows 7  , abbiamo provato TortoiseSVN 1.7.6 a 64 bit su Windows   7 64-bit che ha portato alla seguente problema:

  • Qualsiasi operazione che coinvolge il server (repo-browser, checkout, update, checkin, ...) è insopportabilmente lento ad es
    • aprire il repo browser (10 progetti): 15 min
    • aggiornamento su un checkout fresco di 50 file: 1 min
    • checkin di un singolo file vuoto: 30 sec
  • Tortoise mostra in alternativa normali velocità di trasmissione e 0 byte/s. Molti piccoli file sembrano essere più lenti di alcuni grandi.
  • I risultati connessione lenta in vari errori quando si utilizza neon come http-lib (servo è ancora lento, ma il funzionamento termina con successo senza errori)
  • EasySVN, SmartSVN e il client a riga di comando SVN che viene fornito con TortoiseSVN mostrano lo stesso comportamento . Lo stesso con TortoiseSVN 1.6.16 64-bit.
  • Modifica del protocollo server HTTP (non SSL) non migliora la situazione

D'altra parte

  • TortoiseSVN 1.7.6 a 32 bit su Windows XP funziona bene con il nostro server
  • accesso via browser/WebDAV funziona bene anche sotto Windows 7
  • log lato server non mostrano errori o addirittura gli avvisi

Ho trovato diversi post che si sono lamentati anche del comportamento lento su Windows   7, ma non erano compatibili con il mio conto perché erano operazioni locali o erano limitati a TortoiseSVN.

Poiché non vi è alcuna indicazione che ci sia un problema generale con Subversion su Windows   7, ho il sospetto che potrebbe essere i parametri di rete o le versioni del protocollo del nostro sistema operativo. Ci sono dei parametri che sono noti per influenzare le prestazioni di Subversion?

Devo ammettere che non ho familiarità con quanto esattamente Subversion (o piuttosto neon/serf) si appoggia sul sistema operativo e su quali parti. Qualsiasi informazione in merito sarebbe molto apprezzata.

Ci sono dei parametri nel file 'server' di subversion che dovrei testare? Come valuteresti le mie possibilità che la connessione di Wireshark mi aiuterà?

Esperienze simili, opinioni, suggerimenti, aiuto e cannucce sono benvenuti.

Wireshark mostra intervalli sporadici di ca. 5 secondi nel flusso TCP apparentemente causato da VisualSVN Server.

  • https: il server riconosce il client ciao quindi attende 5 secondi prima di inviare il suo server ciao
  • https: il server riconosce la chiave del client e di prende 5 secondi prima di fornire i suoi dati handshake crittografati
  • https : anche al di fuori della stretta di mano, il server a volte invia un ACK (a livello TCP) e attende 5 secondi prima di inviare qualcosa al client (i dati vengono crittografati quindi è difficile dire se l'interruzione si verifica in un punto di interesse)
  • http: su entrambe le trasmissioni lato server durante l'autenticazione NTLM
  • http: prima di server di invio una bandiera FIN
+0

sei arrivato da qualche parte con questo? –

+0

Grazie per avermelo ricordato. Vedi la mia risposta su questo. – wolfpile

+0

La risoluzione dei nomi di dominio era il mio problema, aggiungendo una voce 'hosts' locale che si animava. – Lankymart

risposta

0

Il problema non è mai stato risolto correttamente. Molto probabilmente, il percorso di rete interno dell'azienda tra il client e il server era in qualche modo sbagliato. La questione è diventata obsoleta quando abbiamo spostato il server SVN su un'altra macchina. Lo stesso setup di server e client funziona bene ora, anche con Windows 7.

7

Un tipico falliscono con Windows 7 su un server più vecchio è il networking IPv6.

Se la macchina non ha un server SVN in ascolto su un indirizzo IPv6 Windows 7 potrebbe ancora provare a eseguire prima un collegamento TCP6 (lo si può vedere in Process Explorer se si guardano i socket aperti del processo TortoiseSVN mentre si prova un operazione), ha un timeout di alcuni secondi e quindi riprova con IPv4.

Le soluzioni semplici sono l'aggiornamento del server a uno compatibile con IPv6 o la disabilitazione di IPv6 per i client Windows   7.

4

Un'altra cosa che è possibile verificare (la risposta sopra non ha funzionato per noi) è le impostazioni di Internet Explorer, specialmente se si dispone di IE9. Abbiamo scoperto che disabilitando l'opzione Automatically detect settings nel Internet Options -> Connection tab -> LAN settings, SVN ha iniziato a funzionare normalmente di nuovo.

+3

Ho aggiornato la tua risposta con i nomi delle opzioni in inglese; Spero non ti dispiaccia. – harpun

0

Ho avuto lo stesso sintomo di un repository molto lento di navigare, lenti aggiornamenti, rallentare tutto.

Il mio server SVN ha due schede Ethernet, quindi ha due indirizzi IP Ethernet. Il server SVN stava solo ascoltando uno degli indirizzi IP. Quindi una risoluzione dei nomi tramite WINS o NetBIOS potrebbe risolvere l'indirizzo IP "sbagliato".

TortoiseSVN riproverebbe, alla fine la risoluzione dei nomi avrebbe trovato l'indirizzo IP "corretto" e le cose avrebbero funzionato.