Velocidad en tiempo de respuesta WebService

4076 views
Skip to first unread message

ErickOrlando

unread,
Jan 6, 2012, 3:54:05 PM1/6/12
to altnet-...@googlegroups.com
Hola Gente:
 
Les escribo porque hace varios días tengo un pequeño inconveniente, estoy desarrollando una solución Windows Forms para Windows Mobile 6 en C# bajo .NET Compact Framework 3.5 y mi aplicativo utiliza un WebService para recuperar cierta información, el problema radica en que la velocidad es muy lenta, pues para traer una información pasan por lo menos 6 segundos hasta tener un resultado, y eso que lo he mejorado pues antes los WebMethods devolvian DataSets que evidentemente son más pesados ahora sólo devuelven clases concretas con los datos exactos.
 
Imagino que la lentitud se debe también a que para que mi dispostivo se conecte a Internet no utilizo WI-FI sino GPRS que también es mucho más lento, pero .NET acaso no genera una especie de "caché" cuando invoca a un WebService? Porque no importa la cantidad de veces que la aplicación realice la llamada siempre demora.
 
También estuve googleando y vi que puedo usar WCF, pero es realmente más rápido?
Desde ya agradezo su respuesta.
 
Saludos.

Ariel Piñeiro

unread,
Jan 6, 2012, 4:04:43 PM1/6/12
to altnet-...@googlegroups.com
Erick, 
        estuve en un proyecto con una arquitectura similar, y sí, realmente es muy lenta la comunicación con ese combo que vos mencionás, hay que ver lo que es lento para cada uno, por lo menos para mí. Intentamos mejorar comprimiendo la información, mejorando el diseño para no hacer llamadas innecesarias, pero el volumen de datos y el enlace era un problema. Finalmente hicimos una re-ingeniería del diseño, arquitectura y la comunicación, utilizando JSON, compresión, y una API RESTFul.

De todas formas, GRPS por lo menos para mí, apesta para una aplicación empresarial, pero bueno, es lo que hay.


Saludos,
Ariel Piñeiro
http://ar.linkedin.com/in/arielpineiro



2012/1/6 ErickOrlando <orland...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/mbzsblbKUIMJ.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

Beyondnet

unread,
Jan 6, 2012, 4:19:18 PM1/6/12
to altnet-...@googlegroups.com

Usa REST

--

Juanma

unread,
Jan 6, 2012, 4:19:58 PM1/6/12
to altnet-...@googlegroups.com
Hola Erick,

Yo he tenido que hacer bastantes desarrollos sobre WinMo con GPRS, y lo más eficiente que he encontrado para comunicar es usar sockets (TcpClient/TcpListener) y serializar la información con Protocol Buffer (la implementación de protobuf.net es muy buena).

WCF no te va a solucionar la vida porque en CF sólo está soportada la serialización xml, por lo que al final vas a tener los mismos problemas que con los servicios web: serialización/deserialización lenta y más tráfico de datos, que encima al ser en una conexión lenta como GPRS...

Un saludo,

Juanma

2012/1/6 Ariel Piñeiro <arie...@gmail.com>



--
Blog: http://blog.koalite.com




Juanma

unread,
Jan 6, 2012, 4:21:14 PM1/6/12
to altnet-...@googlegroups.com
Se me olvidaba, el enlace a protobuffer es: http://code.google.com/p/protobuf-net/

2012/1/6 Juanma <gul...@gmail.com>



--
Blog: http://blog.koalite.com




ErickOrlando

unread,
Jan 6, 2012, 5:42:35 PM1/6/12
to altnet-...@googlegroups.com
Jeje creo que no me explique bien, no tengo problemas con la serialización de los objetos, lo que pasa es que necesito usar los WebServices porque el aplicativo movil necesita extraer datos de una base de datos SQL Server externa, obviamente este servidor no puede estar expuesto a Internet por los riesgos de seguridad que esto implicaría y es x eso que necesito un servicio en "medio" que exponga estos datos y quería saber si hay manera de recuperar esos datos de forma más rápida.
 
Saludos.

Cristian Prieto

unread,
Jan 6, 2012, 9:38:01 PM1/6/12
to altnet-...@googlegroups.com
No entiendo la pregunta, especialmente el significado de "lento"....

Es lento porque...

1. Bajar 1 Mega de informacion en un modem es lento, por ejemplo... Si intentas transmitir todo un grafo gigante atravez de una mala conexion, si, definitivamente es lento, y ahi ni WCF ni REST, ni nada te va a ayudar...

2. Si realmente sabes que lo que estas enviando de vuelta es algo pequeno, por ejemplo 10K y sigue siendo lento, entonces, antes de hecharle la culpa al "webservice" deberias ver cuellos de botella....

a.) La consulta que estas haciendo
b.) Si hay algo mas consumiendote el tiempo en tu app
c.) Si es el proceso de transmision

Un buen developer agota y crea una cola de posibles razones y soluciones antes de afirmar simplemente que algo es lento... IMHO, si ya tienes esa cola de razones, seria fantastico que nos la compartieras, quizas asi podemos ayudarte un poco mas, porque en mi caso el decir simplemente "lento" no me dice nada y me llena la cabeza con mas preguntas que respuestas....

Saludos companeros y exito!

Cristian Prieto


2012/1/7 ErickOrlando <orland...@gmail.com>
Jeje creo que no me explique bien, no tengo problemas con la serialización de los objetos, lo que pasa es que necesito usar los WebServices porque el aplicativo movil necesita extraer datos de una base de datos SQL Server externa, obviamente este servidor no puede estar expuesto a Internet por los riesgos de seguridad que esto implicaría y es x eso que necesito un servicio en "medio" que exponga estos datos y quería saber si hay manera de recuperar esos datos de forma más rápida.
 
Saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/MBMHn4irTJ8J.

Juanma

unread,
Jan 7, 2012, 3:38:55 AM1/7/12
to altnet-...@googlegroups.com
Tal vez el que no se explicó bien fui yo :-)

Asumo que cuando hablas de lento es porque ese mismo web service, invocado en el mismo servidor, va bien. En ese caso, el cuello de botella lo puedes tener:

a) En el proceso en la PDA
b) En las comunicaciones

Como bien dice Cristian Prieto, lo primero sería medir y averiguar dónde está el cuello de botella, pero suponiendo que esté en las comunicaciones, realmente lo que más te va a ayudar es realizar el menor posible de llamadas remotas y hacer que se mueva el menor número posible de datos en cada llamada, y ahí es donde entra el protocolo de serialización. No es lo mismo serializar un DataSet, que en XML, que en JSON, que en binario (como protobuf o datacontractserializer), cada uno es más eficiente que el anterior y supone un menor volumen de datos transmitidos por GPRS. A eso hay que sumarle el tiempo para serializar/deserializar, que en el PC te puede dar más igual, pero en la PDA...

Un saludo,

Juanma

2012/1/6 ErickOrlando <orland...@gmail.com>
Jeje creo que no me explique bien, no tengo problemas con la serialización de los objetos, lo que pasa es que necesito usar los WebServices porque el aplicativo movil necesita extraer datos de una base de datos SQL Server externa, obviamente este servidor no puede estar expuesto a Internet por los riesgos de seguridad que esto implicaría y es x eso que necesito un servicio en "medio" que exponga estos datos y quería saber si hay manera de recuperar esos datos de forma más rápida.
 
Saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/MBMHn4irTJ8J.

Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.



--
Blog: http://blog.koalite.com




Angel Java Lopez

unread,
Jan 7, 2012, 3:45:56 AM1/7/12
to altnet-...@googlegroups.com
Hola gente!


Erick, una pregunta al bulto:

- Creas el objeto cliente (invocador del web service) cada vez, antes de cada llamada?
- Si es asi, hay algun cambio si dejas el objeto creado, y lo reusas en cada llamada?

Angel "Java" Lopez
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/mbzsblbKUIMJ.

Ernesto Cárdenas

unread,
Jan 7, 2012, 2:03:16 PM1/7/12
to AltNet-Hispano
Hola Todos

Han revisado el Windows Server AppFabric? lo he probado para dar
soporte a WCF sobre sockets, no tuve que codificar nada, solo
configurar bien los .config y los tiempos de respuesta cayeron
brutalmente... me dio una muy buena impresion.

El problema es que esto no corre sobre Windows Server Web Edition, se
necesita Standard o superior, pero me dejo una muy buena impresion.

Suerte!
Ernesto

Erick Orlando

unread,
Jan 8, 2012, 10:06:54 AM1/8/12
to altnet-...@googlegroups.com
Muchas gracias por estos consejos, voy a tener que revisar entonces JSON y la serialización binaria para ver si esto puede también solucionar el problema que tengo, y eso que yo construyo un unico objeto invocador al WebService en toda la aplicación, y unicamente lo destruyo cuando la aplicación termina.
 
Pero bueno leyendo sus sugerencias estoy más q satisfecho. 
Gracias.
 

From: gul...@gmail.com
Date: Sat, 7 Jan 2012 09:38:55 +0100
Subject: Re: [altnet-hispano] Re: Velocidad en tiempo de respuesta WebService
To: altnet-...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google..com/group/altnet-hispano?hl=es.

Erick Orlando

unread,
Jan 8, 2012, 10:08:47 AM1/8/12
to altnet-...@googlegroups.com
Angel:
 
Efectivamente, yo creo una sola vez un objeto invocador y luego ese objeto lo llamo en otras partes de la aplicación pero aún asi los tiempos de respuesta no mejoran. Creo que tiene mucho que ver que se conecte por GPRS ya que el movil tiene un chip de Movistar ¬¬.
 
Saludos.
 

Date: Sat, 7 Jan 2012 05:45:56 -0300
Subject: Re: [altnet-hispano] Velocidad en tiempo de respuesta WebService
From: ajlop...@gmail.com
To: altnet-...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google..com/group/altnet-hispano?hl=es.

Eugenio Pace

unread,
Jan 9, 2012, 12:56:06 PM1/9/12
to altnet-...@googlegroups.com
Erick,

En las aplicaciones moviles que he construido, especialmente en aquellas con restricciones serias de ancho de banda y latencia (me refiero a enlaces que se miden en Kb/s: modems, x.25, etc.), la arquitectura que he usado es:

UI <–> Local Storage <–> Sync <–> Remote Service

Es decir que la interfaz de usuario siempre interactua con algun repositorio local y el proceso de comunicacion con el endpoint remoto esta desacoplado (y potencialmente se ejecuta en el background).

En la plataforma que estas utilizando (WM 6), tienes SQL Compact disponible, lo cual simplifica cosas como manejo de concurrencia, pero no es un requerimiento por supuesto.

Tambien me sumo a la recomendacion de usar protocolos y formatos mas simples y livianos (e.g. JSON, REST), aunque no necesariamente por temas de eficiencia solamente. Mi preferencia es primero por simplicidad, segundo por eficiencia. La otra recomendacion es que midas todo para optimizar en donde valga la pena. 

A veces, cosas que suenan buen en papel, no lo son en la practica. Por ejemplo: habilitar compresion puede parecer una buena idea para optimizar el uso de red, pero eso es a costa de utilizar mas CPU (y consecuentemente mas bateria).  

Saludos
Eugenio


2012/1/8 Erick Orlando <orland...@gmail.com>
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

Jose Gregorio Suarez

unread,
Aug 23, 2016, 11:53:22 PM8/23/16
to AltNet-Hispano
Saludos Erick, tengo un tema similar, podrias compartir cuales fueron las soluciones para resolver el problema de los 6 segundos.

Muy cordialmente,

Erick Orlando

unread,
Aug 23, 2016, 11:59:04 PM8/23/16
to Jose Gregorio Suarez, AltNet-Hispano

Hola José, ya casi ni me acordaba que hice esta pregunta en el foro (fue en el 2012), lo resolví creando un RESTful Service con WCF y transmitiendo JSON, de esta manera logré que los datos enviados sean mucho más cortos, y a menos KB de transferencia es mayor la performance. Por lo cual hizo que mi aplicativo móvil de Windows Mobile fuera súper rápido, recuerdo que hasta recibí un bono en la empresa por semejante logro jeje.

 

Saludos!

Erick Orlando

 

Enviado desde Correo para Windows 10

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/altnet-hispano/5IvvHQjvknE/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

 

Juan María Hernández

unread,
Aug 26, 2016, 2:18:32 AM8/26/16
to altnet-...@googlegroups.com
Hola José,

Hace mucho, mucho tiempo, tuve un escenario parecido y el problema no sólo estaba en la parte de red (ancho de banda y latencia), sino también en que el terminal con Windows Mobile era muy lento para serializar/deserializar información.

Al final acabé usando comunicación por sockets y serialización a través de protocol buffers (https://github.com/mgravell/protobuf-net), y era entre 10 y 100 veces más rápido, aunque te toca implementar el servidor y el cliente (que tampoco es muy complicado con un TcpListener y un TcpClient).

Un saludo,

Juanma.

Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a altnet-hispano+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-hispano@googlegroups.com.


Visita este grupo en https://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

 

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispano+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-hispano@googlegroups.com.

Visita este grupo en https://groups.google.com/group/altnet-hispano.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Carlos Admirador

unread,
Oct 14, 2016, 1:27:22 PM10/14/16
to AltNet-Hispano
Hola gente!!

Para un tuning de WCF: configuraciones en IIS, machine.config y web.config,

serviceThrottling, DataContract Serializer  , NetTCP binding
under <netTcpBinding> setting the listenBacklog, maxConnections, and maxBuffer* value high

comunicación por sockets y serialización a través de protocol buffers (https://github.com/mgravell/protobuf-net),  es muy a bajo nivel, implementar el servidor y el cliente ( con un TcpListener y un TcpClient) yo lo veo complicado desde mi gran ignorancia claro. Sin ver un ejemplo que me abra los ojos, buscaré en github.

Saludotes!!
Carlos

Carlos Admirador

unread,
Oct 14, 2016, 2:44:09 PM10/14/16
to AltNet-Hispano
Ampliando...

A nivel general WCF – ASP.NET se considera trabajar con estos valores en la configuración:

system.servicebehaviors -> throttling values
system.net -> connectionManagement -> maxConnection
processModel -> maxWorkerThreads=”500″
maxIoThreads=”500″
minWorkerThreads=”250″
minIoThreads=”250″

 


Para WCF:


·         Changed the binding to netTcpBinding.

·         Changed throttling values:

·         WCF: maxConcurrentCalls, maxConcurrentSessions, maxConcurrentInstances all to 1000

·         TCP binding: maxConnections=1000

·         Threadpool: Min worker threads = 1000, Min IO threads = 2000


<serviceBehaviors>

  <behavior name="defaultServiceBehavior">

     <serviceThrottling maxConcurrentCalls="100"

         maxConcurrentInstances="100" maxConcurrentSessions="100" />  


There are three main properties properties provided by default WCF throttling.

1- maxConcurrentCalls – How many number of request can be accepted by a service in a second.

2- maxConcurrentSessions – How many number of request can be processed by a service in a second.

3- maxConcurrentInstances – How many number of instances of service can be created by a service in a second.

 

 

Now before moving further, the above values are default values if one is using .NET 4.0 or less. But if you are using the .NET 4.5, Microsoft made it dynamic and changed it significantly and as

maxConcurrentCalls – 16 times of number of processors
maxConcurrentSessions – 100 times of number of processors
maxConcurrentInstances –  Sum of maxConcurrentCalls and maxConcurrentSession.

Normally at our production servers, we used 8 or 16 or more processors. Correct. let’s see the value in case of 8 cores

maxConcurrentCalls – 144
maxConcurrentSessions – 800
maxConcurrentInstances –  944

 

 

<system.net>

  <connectionManagement>

    <add address="*" maxconnection="100" />

  </connectionManagement>

</system.net

 

<connectionManagement>

   <add address="myapi.com" maxconnection="12"/>

   <add address="yourapi.com" maxconnection="8"/>

   <add address="hisapi.com" maxconnection="4"/>

  </connectionManagement>

 

 



processModel

   enable="true"

   timeout="Infinite"

   idleTimeout="Infinite"

   shutdownTimeout="00:00:05"

   requestLimit="Infinite"

   requestQueueLimit="5000"

   restartQueueLimit="10"

   memoryLimit="60"

   webGarden="false"

   cpuMask="0xffffffff"

   userName="machine"

   password="AutoGenerate"

   logLevel="Errors"

   clientConnectedCheck="00:00:05"

   comAuthenticationLevel="Connect"

   comImpersonationLevel="Impersonate"

   responseDeadlockInterval="00:03:00"

   responseRestartDeadlockInterval="00:03:00"

   autoConfig="false"

   maxWorkerThreads="100"

   maxIoThreads="100"

   minWorkerThreads="40"

   minIoThreads="30"

   serverErrorMessageFile=""

   pingFrequency="Infinite"

   pingTimeout="Infinite"

   maxAppDomains="2000"

/>

 

 

<httpRuntime>

The <httpRuntime> element configures the ASP.NET runtime settings. You can specify these at the machine, site, application, and subdirectory levels. The default settings from Machine.config are as follows.

<httpRuntime executionTimeout="90" maxRequestLength="4096" 
             useFullyQualifiedRedirectUrl="false" minFreeThreads="8" 
             minLocalRequestFreeThreads="4" appRequestQueueLimit="100" 
             enableVersionHeader="true"/> 

For a detailed description of each attribute, see "<httpRuntime> Element" in the .NET Framework documentation at http://msdn.microsoft.com/en-us/library/e1f13641(VS.71).aspx.




Thread Pool Attributes

 

 

The following list describes key attributes (in <processModel> and <httpRuntime>) in the machine.config file related to ASP.NET ThreadPool.

The list also discusses the scenarios where each attribute applies:

  • maxconnection. If your application makes calls to a remote Web service and the requests are waiting for the call to complete, you can increase the CPU utilization and your application performance by changing the maxconnection attribute on the <ConnectionManagement> element in Machine.config. The default values are as follows.
  •  
  • <connectionManagement>
  •   <add address="*" maxconnection="2"/>
  • </connectionManagement>

 

Increasing maxconnection enables more calls to be executed concurrently to a remote Web service. This attribute does not affect local Web service calls. An increase in the number of concurrent calls causes an increase in the utilization of threads that are used to make the remote calls.

Increasing maxconnection also can lead to an increase in CPU utilization. This increase in CPU utilization is caused by the fact that more incoming requests can be processed by ASP.NET instead of having the incoming requests wait for their turn to call the Web service. You need to balance the maxconnection with the other attributes discussed in this list and the actual CPU utilization.

  • maxWorkerThreads and maxIoThreads. These attributes define the maximum number of worker and I/O threads that the ASP.NET worker process is allowed to create. These values do not reflect the actual number of threads that are created by the worker process. The maximum value for these attributes is 100 per processor.

As described earlier, if you increase maxconnection, you cause increased concurrent processing, which requires a greater number of worker and I/O threads. Consider the following guidelines when tuning these attributes:

    • Change these attributes only if your processor utilization is below the threshold limits defined by your application's performance objectives.
    • Avoid increasing these attributes if the requests are not waiting on an I/O call but are actually performing CPU-intensive work. Increasing these attributes in this circumstance can negatively affect performance because the already stressed processor now has to handle increased thread context switching.
    • If your application makes a short-running I/O call (for example, to a remote Web service), you might not need to increase these values because the calling threads are not blocked for an excessive period.
    • If your application makes a long-running I/O call and your system has idle CPU, you can safely consider increasing these attributes along with the other related attributes discussed in this section. If your system does not have idle CPU, then you probably should not increase these attributes.

If you have a Web service on the same server as your Web application, consider the following to decide when to increase the default values:

    • Increase these attributes only if your processor utilization is below the threshold limits defined by your application's performance objectives.
    • Avoid increasing these attributes if requests are not waiting on an I/O call but are performing CPU-intensive tasks. Increasing these attributes in this situation can negatively affect performance because the already stressed processor now has to handle increased thread switching.
    • maxconnection and minFreeThreads. These attributes do not have any effect in scenarios where you make only local Web services calls.
  • minFreeThreads. This attribute defines the number of threads that can be used for work other than processing incoming requests to the worker process. This attribute prevents the ASP.NET process from using a thread from the thread pool to handle a new HTTP request if this would mean that the free thread count drops below this limit. The attribute is specified on the <httpRuntime> element and has a default value of 8.

You can use this attribute to help prevent deadlocks by ensuring that a thread is available to handle callbacks from pending asynchronous requests. A deadlock can occur if all of the threads in the thread pool are currently in use handling incoming HTTP requests, and one or more of those requests are waiting for asynchronous callbacks. In this situation, there are no available threads to service the callback. You can setminFreeThreads to ensure that some free threads are available to process the callbacks.

Increasing minFreeThreads means that you reserve more threads to make remote calls. In all cases, you should ensure that maxWorkerThreads minFreeThreads >=12. Twelve is the optimum number of threads that should be made available to the ASP.NET worker process to service requests. This value means that ASP.NET cannot execute more than twelve requests concurrently. This limit is based on a series of performance tests, which demonstrate that normally the worker process uses four of these threads. If the processor is fully utilized (greater than 95 percent utilization) and your application makes long-running calls, the worker process is likely to use all twelve threads.

You might want to increase the attribute from the default values in the following scenarios:

    • You have increased maxWorkerThreads and maxIoThreads.
    • You have increased maxconnection to service a greater number of back-end calls, and hence require more threads to be made available for this purpose.
    • You might need to consider changing this attribute whenever you make long running calls which block your execution. This is most beneficial when the work is not computationally expensive for the server where you make the changes.
  • minLocalRequestFreeThreads. For a Web application using the Web service located on the same computer, you should consider decreasing the value of minLocalRequestFreeThreads when you need to give priority to processing local calls. This attribute defines the minimum number of free threads that ASP.NET keeps available so that requests from localhost are not queued. Before processing a local request, the runtime checks to see if at least this minimum number of worker threads are available. If fewer threads are available, the request is queued.

The default setting is four, so if only three worker threads are available the local request is queued. When this value is decreased, ASP.NET starts to use threads more aggressively, resulting in less local queuing.

Note   Requests from remote clients start to queue when the free threads in the thread pool fall below the value ofminFreeThreads.

If you decrease the value of minLocalRequestFreeThreads value without changing the minFreeThreads attribute, you are effectively telling the worker process to give priority to completing calls from the local server.

 

 

 

https://msdn.microsoft.com/en-us/library/ms998583.aspx

https://msdn.microsoft.com/en-us/library/windows/hardware/dn567678(v=vs.85).aspx

Saludotes!!

Carlos 

Message has been deleted

Carlos Admirador

unread,
Mar 13, 2018, 5:27:22 PM3/13/18
to AltNet-Hispano
Ampliando...

Respecto a WCF Services:

BizTalk: Performance tips for high volume WCF calls
http://social.technet.microsoft.com/wiki/contents/articles/33642.biztalk-performance-tips-for-high-volume-wcf-calls.aspx


Me pregunto si habrá una guía o libro blanco sobre High Performance REST Services?

Cualquier ayuda se agradecería. Muchas gracias de antemano.


 


Reply all
Reply to author
Forward
0 new messages