tengo unWPF cliente solicitando datos a través deWCF servicio alojado enIIS 7. El método de servicio realiza una llamada a un procedimiento almacenado (SQL 2012) utilizandoEF para recuperar algunos datos.

Hay una gran cantidad de datos para cargar, por lo que el cliente realiza varias llamadas al método de servicio en un esfuerzo por "dividir" la carga de datos y evitar grandes cargas útiles y tiempos de espera.

Utilizamos los proxies de servicio generados que se extienden desdeSystem.ServiceModel.ClientBase<T>.

También estamos usando un enlace http personalizado con codificación binaria (desdeaquí) - la implementación real se muestra aquí:

<customBinding>
   <binding name="CustomBinding_IPointDataAccess" closeTimeout="00:01:00"
      openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00">
      <binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" maxSessionSize="2048">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="16384" />
      </binaryMessageEncoding>
      <httpTransport manualAddressing="false" maxBufferPoolSize="524288"
         maxReceivedMessageSize="2147483647" allowCookies="false" authenticationScheme="Anonymous" bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" maxBufferSize="2147483647" proxyAuthenticationScheme="Anonymous" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" />
   </binding>

Además, la compresión dinámica está activada en IIS. Puedo ver las solicitudes en Fiddler, y el tamaño del cuerpo del mensaje es correcto (~ 50KB) yEl 99% de las solicitudes se devuelven en uno o dos segundos.. ¡Perfecto!

Sin embargo, con casi todas las iteraciones, hay una llamada en el grupo que tarda unos minutos en completarse, y no sé por qué ... MisendTimeOut en el cliente fue en 1 minuto y, naturalmente, que una llamada fallaría. Lo extendí a 10 minutos, y la llamada parece completarse en poco más de 2 minutos, aunque a veces tomaría incluso más tiempo. El problema parece ser muy aleatorio: podría ser la primera llamada, podría ser la llamada número 30. Pero es muy reproducible.

Coloqué algo de registro alrededor de la llamada al procedimiento almacenado en el método de servicio WCF y se ejecuta y recupera los datos en menos de un segundo. Entonces, no creo que sea un problema de base de datos.

Usando Fiddler, la llamada problemática genera una salida similar a la siguiente:

ACTUAL PERFORMANCE
--------------
ClientConnected:     14:02:42.959
ClientBeginRequest:  14:03:01.224
GotRequestHeaders:   14:03:01.224
ClientDoneRequest:   14:03:01.574
Determine Gateway:   0ms
DNS Lookup:      0ms
TCP/IP Connect:  46ms
HTTPS Handshake:     0ms
ServerConnected:     14:05:16.021
FiddlerBeginRequest: 14:05:16.021
ServerGotRequest:    14:05:16.021
ServerBeginResponse: 14:03:04.784
GotResponseHeaders:  14:05:16.561
ServerDoneResponse:  14:05:16.611
ClientBeginResponse: 14:05:16.611
ClientDoneResponse:  14:05:16.611

Note el tiempo significativo entreServerBeginResponse yGotResponseHeaders. Esto parece sorprendentemente similar al problema vistoaquí.

Activé el servicio de rastreo de WCF y, a simple vista, no hay errores ni advertencias, pero realmente no tengo mucho sentido de lo que estoy viendo más allá de lo básico.

¿Cómo puedo determinar qué y dónde está el problema? ¿Es la serialización? ¿Es un problema de red? ¿No puede el servidor mantenerse al día con el cliente enviando tantas solicitudes?

He intentado ajustar la limitación de WCF en el archivo de configuración agregando el apropiadoserviceBehaviors, pero esto no hizo una diferencia.

Debo mencionar que estoy haciendo esto a través de una conexión VPN, pero otras cosas como las transferencias de archivos, las conexiones de escritorio remoto funcionan bien. Parece bastante confiable.

Puedo proporcionar más detalles si es necesario.

Editar (6.10.2013): No estoy seguro de si esto está relacionado o solo por casualidad, pero un par de veces, he notado que en la llamada problemática, el tamaño del cuerpo es significativamente menor que el de los demás. Este no es el caso cada vez, pero puede proporcionar algunas pistas. Aquí hay una captura de pantalla de Fiddler para mostrarle qué tan consistente debe ser el tamaño del cuerpo en cada llamada. La entrada seleccionada (# 21) es mucho más pequeña que las otras en tamaño, pero tarda más de 2 minutos en completarse.

Curiosamente, esta vez recibí una excepción. La excepción no sucede siempre.

System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)