2012-05-31 26 views
9

Meine Firma verwendet derzeit TortoiseSVN 1.6.16 32-Bit unter Windows XP, um über HTTPS mit einem VisualSVN-Server 2.1.19 zu verbinden, der auf einem Windows Server 2003 im selben Netzwerk läuft (kein Proxy). Wir verwenden ein selbstsigniertes Zertifikat und eine Kerberos-Authentifizierung mit Windows-Anmeldeinformationen (ich nehme an, dies ist eine VisualSVN-spezifische Funktion). In diesem Setup funktioniert alles gut.Subversion unerträglich langsam unter Windows 7

Wenn mein Unternehmen auf Windows 7   zu bewegen entschieden, haben wir versucht TortoiseSVN 1.7.6 64-Bit-Windows   7 64-Bit, das in dem folgende Problem geführt:

  • Jede Operation den Server beteiligt (Repobrowser, Checkout, Update, Einchecken, ...) ist unerträglich langsam zB
    • Öffnen des Repo-Browser (10 Projekte): 15 min
    • Update auf eine neue Kasse von 50 Dateien: 1 min
    • checkin einer einzelnen leere Datei: 30 sec
  • Schildkröte zeigt alternativ normale Übertragungsgeschwindigkeiten und 0 Byte/s. Viele kleine Dateien scheinen langsamer zu sein als ein paar große.
  • Die langsame Verbindung führt zu verschiedenen Fehlern bei der Verwendung von Neon als HTTP-lib (serf ist immer noch langsam, aber der Betrieb beendet erfolgreich ohne Fehler)
  • EasySVN, SmartSVN und die Befehlszeilen Client SVN, das das gleiche Verhalten mit TortoiseSVN zeigen kommt . Selben mit TortoiseSVN 1.6.16 64-Bit.
  • das Server-Protokoll HTTP ändern (kein SSL)
  • die Situation nicht

Auf der anderen Seite

  • TortoiseSVN 1.7.6 32-Bit-Windows XP funktioniert gut mit unserem Server
  • nicht verbessert
  • Zugriff über Browser/WebDAV funktioniert auch unter Windows 7
  • Server-Seite protokolliert Fehler nicht zeigen oder sogar Warnungen

Ich habe mehrere Beiträge gefunden, die sich auch über langsames Verhalten auf Windows   7 beschwerten, aber sie passten nicht zu meiner Rechnung, weil sie lokale Operationen waren oder auf TortoiseSVN beschränkt waren.

Da es keinen Hinweis darauf gibt, dass es ein allgemeines Problem mit Subversion unter Windows   7 gibt, vermute ich, dass es die Netzwerkparameter oder Protokollversionen unseres Betriebssystems sein könnten. Gibt es Parameter, von denen bekannt ist, dass sie die Leistung von Subversion beeinflussen?

Ich muss zugeben, ich bin nicht vertraut mit, wie genau Subversion (oder eher neon/serf) auf das Betriebssystem angewiesen ist und auf welchen Teilen. Irgendwelche Informationen darüber würden sehr geschätzt werden.

Gibt es irgendwelche Parameter in der Subversion 'Server' Datei, die ich testen sollte? Wie würdest du meine Chancen einschätzen, dass Wireshark'ing die Verbindung mir helfen wird?

Ähnliche Erfahrungen, Meinungen, Tipps, Hilfe und Strohhalme sind willkommen.

Wireshark zeigt sporadische Lücken von ca. 5 Sekunden im TCP-Stream, der offensichtlich von VisualSVN Server verursacht wurde.

  • https: Der Server erkennt der Client-Hallo dann für 5 Sekunden wartet, bevor er seine Server-Hallo
  • https Senden: Der Server erkennt den Client-Schlüssel und als dauert 5 Sekunden vor dem verschlüsselten Handshake Daten
  • https Liefern : Sogar außerhalb des Handshakes sendet der Server manchmal einen ACK (auf TCP-Ebene) und wartet dann 5 Sekunden, bevor er etwas zurück zum Client sendet (die Daten sind verschlüsselt, so dass es schwierig ist, festzustellen, ob der Bruch an einem bestimmten Punkt auftritt)
  • http: bei beiden serverseitigen Übertragungen während der NTLM-Authentifizierung
  • http: vor Server
+0

Haben Sie mit diesem Gerät überhaupt etwas erreicht? –

+0

Danke für die Erinnerung an mich. Siehe meine eigene Antwort dazu. – wolfpile

+0

Domain Name Auflösung war mein Problem hinzugefügt einen lokalen 'Hosts' Eintrag und es zum Leben erweckt. – Lankymart

Antwort

0

Das Problem wurde nie richtig aufgeklärt. Höchstwahrscheinlich war der unternehmensinterne Netzwerkpfad zwischen dem Client und dem Server irgendwie fehlerhaft. Die Angelegenheit wurde obsolet, als wir den SVN Server auf einen anderen Rechner verschoben haben. Das gleiche Setup von Server und Clients funktioniert jetzt gut, sogar mit Windows 7.

7

Ein typischen nicht mit Windows 7 gegen einen älteren Server ein FIN-Flag Senden ist IPv6-Netzwerken.

Wenn auf Ihrem Computer kein SVN - Server eine IPv6 - Adresse überwacht, versucht Windows 7 möglicherweise noch, zuerst eine TCP6 - Verbindung herzustellen (Sie können es in Process Explorer sehen, wenn Sie die geöffneten Sockets des TortoiseSVN - Prozesses betrachten Operation), hat dies eine Zeitüberschreitung von einigen Sekunden und wiederholt dann mit IPv4.

Einfache Lösungen sind entweder aktualisieren Sie Ihren Server auf einen IPv6-fähigen oder deaktivieren Sie IPv6 für die Windows 7 Clients.

4

Eine andere Sache, die Sie verifizieren konnten (die obige Antwort funktionierte nicht für uns), ist die Internet Explorer-Einstellungen, besonders wenn Sie IE9 haben. Wir haben festgestellt, dass durch Deaktivieren der Option Automatically detect settings in der Internet Options -> Connection tab -> LAN settings, SVN wieder normal funktioniert.

+3

Ich habe Ihre Antwort mit englischen Optionsnamen aktualisiert; Ich hoffe, es macht dir nichts aus. – harpun

0

Ich hatte das gleiche Symptom eines sehr langsamen Repository durchsuchen, langsame Updates, langsam alles.

Mein SVN-Server hat zwei Ethernet-Karten, also zwei Ethernet-IP-Adressen. Der SVN-Server hat nur eine der IP-Adressen abgefragt. So könnte eine Namensauflösung über WINS oder NetBIOS auf die "falsche" IP-Adresse auflösen.

TortoiseSVN würde versuchen, schließlich die Namensauflösung würde die "richtige" IP-Adresse finden, und die Dinge würden funktionieren.