desaceleración servicio web

Question

Tengo una desaceleración servicio web. Mi servicio (web) se encuentra en gsoap y manejado C ++. No es IIS / Apache alojado, pero habla en XML. Mi cliente está en .NET El tiempo de cálculo servicio es la luz (<0,1 s para preparar respuesta). Espero que el servicio sea suave, rápido y tener buena disponibilidad. Tengo cerca de 100 clientes, el tiempo de respuesta es obligatoria 1s. Los clientes tienen alrededor de 1 solicitud por minuto. Los clientes están comprobando la presencia servicio web mediante la prueba de puerto TCP abierto. Por lo tanto, para evitar la posible congestión, di vuelta a gSOAP KeepAlive falsa. Hasta ahí todo funciona muy bien: me cabía dentro veo conexiones en TCPView (sysinternals)

Nuevo programa de sincronización especial llama ahora el servicio en un bucle. Es más alta carga, pero todo se procesa en menos de 30 segundos. Con sysinternals TCPView, veo que alrededor de 1 mil conexiones están en TIME_WAIT. Ellos desaceleración del servicio y Toma segundos para el servicio para responder, ahora.

Podría ser que necesito para restablecer la conexión SoapHttpClientProtocol? Alguien tiene fantasmas TIME_WAIT con una llamada de servicio web en un bucle?

Answer 1

Parece que usted no está cerrando la conexión después de la llamada y la apertura de nuevas conexiones en cada petición. O bien cerrar la conexión o reutilizar las conexiones abiertas.

Answer 2

Tenga mucho cuidado con las implementaciones mencionadas anteriormente. Existen serios problemas con ellos.

1. La implementación descrita en yakkowarner.blogspot.com/2008/11/calling-web-service-in-loop.html (comentario anterior):

   PROBLEMA: Todo su trabajo se puede limpiar a cabo la próxima vez que vuelva a generar el servicio web utilizando wsdl.exe y se le va a olvidar lo que no mencionar que esta revisión es bastante hacky apoyándose en una cadena de mensaje para tomar medidas.

2. La implementación descrita en forums.asp.net/t/1003135.aspx (comentario anterior):

   PROBLEMA: está seleccionando un punto final entre 5000 y 65535 por lo que a primera vista esto parece una buena idea. Si se piensa en ello no hay manera (al menos ninguno que se me ocurre) que se puede reservar puertos que se utilizarán más adelante. ¿Cómo se puede garantizar que el siguiente puerto en la lista no se utiliza actualmente? Usted va a recoger secuencialmente hasta puertos para utilizar y si alguna otra aplicación elige un puerto que es el siguiente en la lista, entonces usted está regado. ¿Y si alguna otra aplicación que se ejecuta en la máquina cliente comienza a usar puertos aleatorios por sus conexiones - que sería regado en puntos impredecibles en el tiempo. Se podría AZAR recibirá un mensaje de error como "host remoto no puede ser alcanzado o no está disponible." - aún más difícil de solucionar

A pesar de que no se le puede dar la solución adecuada a este problema, algunas cosas que puede hacer son:

1. Trate de minimizar el número de solicitudes de servicios web o los extendió más durante un período de tiempo más largo
2. Para su tipo de aplicaciones tal vez los servicios web no era la correcta arquitectura - algo con el tiempo de respuesta de 1 ms que usted debe utilizar un sistema de mensajería - no es un servicio web
3. Establecer el número de su sistema operativo de conexiones permitidas a 65K usando el registro como en Windows
4. configura el tiempo de sistema operativo que permanecen en los zócalos TIME_WAIT a un número inferior (esto presenta su propia lista de problemas)