Límite de velocidad de connection de SharpSVN para localhost?

Usamos SharpSVN para acceder mediante progtwigción a los repositorys SVN. Ahora tenemos el problema de que el acceso a los repositorys locales a través de svn: // o http: // urls es muy lento: cada acceso necesita al less un segundo y nuestra aplicación necesita search un set de properties y listdos de directorys.

Podríamos reproducir el problema en dos máquinas diferentes, ambas son Windows 7 de 32 bits y están en el mismo dominio. Los serveres SVN son VisualSVN 2.1.9 para http: // urls y CollabNet 1.6.17 para svn: // urls. Aparece para las conexiones a través de "localhost" y a través del nombre de host. Aparece en nuestra aplicación C #, así como también en una pequeña aplicación de testing que usa IronPython y cuando se llama al command SharpSvn svn.exe.

Este problema no ocurre al acceder cuando se accede a repositorys remotos (tanto un Linux como un server de Windows XP); aquí, cada acceso está entre 0.01 y 0.08 segundos, lo que se espera debido a la latencia de la networking. El problema tampoco ocurre al acceder a los repositorys locales a través de file: // urls o al acceder a los repositorys a través de las herramientas de command-line svn "nativas" de CollabNet.

Ahora mi pregunta es: ¿tiene Windows 7 o .NET o SharpSVN algún límite incorporado que solo se aplica a las conexiones de localhost?

(Además: ahora descubrí que este límite también se aplica cuando se conecta a través de un pequeño progtwig de testing C # usando System.Net.Sockets.TcpClient:

Servidor:

using System; using System.IO; using System.Net; using System.Net.Sockets; namespace TcpSpeedServer { class Program { public static void Main() { Int32 port = 47011; IPAddress localAddr = IPAddress.Parse("127.0.0.1"); var server = new TcpListener(localAddr, port); server.Start(); Console.WriteLine("Listening on {0} : {1}", localAddr, port); ulong count = 0; // Enter the listening loop. while(true) { using (var client = server.AcceptTcpClient()) { Console.WriteLine("Connected: {0} {1}!", count, client.Client.RemoteEndPoint); count += 1; using (var stream = client.GetStream()) { using (StreamWriter writer = new StreamWriter(stream)) using (StreamReader reader = new StreamReader(stream)) { string query = reader.ReadLine(); writer.WriteLine("GET / HTTP/1.0"); writer.WriteLine(); writer.Flush(); } } } } } } } 

Cliente:

 using System; using System.Collections.Generic; using System.IO; using System.Net.Sockets; using System.Threading; namespace TcpSpeedTest { class Program { const bool ASYNC = false; static DateTime s_now; public static void Main(string[] args) { var liste = new List<object>(); s_now = DateTime.Now; for (int i=0; i < 100; i += 1) { if (ASYNC) ThreadPool.QueueUserWorkItem(connect, i); else connect(i); } Console.WriteLine("outer: " + (DateTime.Now - s_now)); Console.ReadLine(); } private static void connect(object i) { DateTime now = DateTime.Now; using (TcpClient client = new TcpClient("localhost", 47011)) { var stream = client.GetStream(); using (StreamWriter writer = new StreamWriter(stream)) using (StreamReader reader = new StreamReader(stream)) { writer.WriteLine("GET / HTTP/1.0"); writer.WriteLine(); writer.Flush(); string result = reader.ReadLine(); } } Console.WriteLine(string.Format("inner: {0} - {1} - {2}", i, DateTime.Now - now, DateTime.Now - s_now)); } } } 

Entonces, este problema parece no ser específico de subversión).

Adición2: cuando se ejecuta el cliente en Mono 2.10 para Windows, el problema no aparece. Entonces parece ser específico para .NET framework.

Adición3: parece ser un problema relacionado con IPv6. El server solo escucha en IPv4, pero el nombre de host también se resuelve en IPv6. Ahora parece que el código del sistema operativo testing internamente la connection IPv6 y luego de restablecer la connection espera 1 segundo antes de volver a IPv4. Y este juego se repite para cada bash de connection. http://msdn.microsoft.com/en-us/library/115ytk56.aspx documenta que para TcpClient (¡gracias a Andreas Johansson de los foros de MSDN por la pista!), y parece que la APR utilizada internamente por Apache utiliza una mecanismo similar.

La adición 3 también es la solución a su problema. Para solucionarlo, haga que el file DNS / hosts resuelva solo en una dirección IPv4 o haga funcionar los serveres IPv6.

Puede ingresar en C:\Windows\System32\drivers\etc\hosts algo como:

 127.0.0.1 localhost-ipv4 

Y luego usa ese nombre para conectarte.

También puede hacer que svnserve escuche direcciones IPv6. Una búsqueda rápida de las opciones de svnserve [revelado] [1] de que su valor pnetworkingeterminado es IPv6, por lo que en sus parameters de inicio es probablemente un --listen-host . Intente eliminar eso, o cuando no esté presente forzándolo a ejecutarse en IPv6.

Lo mismo se puede hacer para el server web Apache:

 Listen 0.0.0.0:80 Listen [::]:80