Velocidad en tiempo de respuesta WebService
ErickOrlando
Ariel Piñeiro
Ariel Piñeiro
http://ar.linkedin.com/in/arielpineiro
--
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
Usa REST
--
Juanma
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
--
Blog: http://blog.koalite.com
Juanma
--
Blog: http://blog.koalite.com
ErickOrlando
Cristian Prieto
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
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
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
--
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
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
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
Erick Orlando
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
Eugenio Pace
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Jose Gregorio Suarez
Muy cordialmente,
Erick Orlando
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!
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
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
Para un tuning de WCF: configuraciones en IIS, machine.config y web.config,
under <netTcpBinding> setting the listenBacklog, maxConnections, and maxBuffer* value high
Creating high performance WCF services https://weblogs.asp.net/sweinstein/creating-high-performance-wcf-services
Carlos Admirador
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
<connectionManagement>
<add address="*" maxconnection="100" />
</connectionManagement>
<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
Carlos Admirador
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.