Hola Carlos,

Tenes razon, lo que dice Oscar puede ser mejor si tenes muchos request que
consumen poco procesador y tardan bastante… pero  creo que con reconfigurar
IIS para que haya mas worker process en el AppPool seria lo mismo (de
cualquier forma vas a necesitar 1 thread por request, sea o no uno de
ASP.NET)… no?

Ahora, si pensas meter los threads que hacen el trabajo en otro servidor ya
cambia mucho la cosa…

 

Con respecto a MQ, no sé si es eficiente o no para buscar mensajes por Id
(imagino que no), pero obviamente no es la función de MQ…. Creo que es mejor
como vos decis, usando SQLServer…

 

Saludos!,

Diego

 

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Peix
Sent: Martes, 04 de Diciembre de 2007 09:05 a.m.
To: [email protected]
Subject: [puntonet] Web service asincronico ?

 

Hola Diego,

 

La diferencia entre un WS que quede procesando y el cliente maneje el pedido
asincronico y lo que propone Oscar es "Escalabilidad". IIS y ASP.NET estan
preparados para atender muchas peticiones pero con la condicion de que sean
de ejecucion breve, muy breve. ASP.NET muere tempranamente si te demoras en
responder la solicitud, incluso es sorprendente que con unos pocos clientes
puedas tirarlo por el piso. Esto no es un error de diseño en ASP.NET, mas
bien es porque los diseñadores asumen algunos puntos de partida, uno de
ellos es que el request debe ser resuelto lo mas rapido posible.

 

El tema que plantea Marcelo tiene dos salidas, si el tiene requests que
impliquen no tiene mas de 10 o 15 requests concurrentes (por ejemplo, si el
request tarda 1 segundo y tiene 100 clientes que se comunican cada 10
segundos, tiene un promedio de 10 clientes concurrentes), entonces puede
intentar ver si funciona con la solucion simple (sincronico o blocking del
lado del server y asincronico del lado del cliente). Si, en cambio, necesita
mas capacidad, probablemente necesite algo como lo que propone Oscar.

 

La solucion que vos mencionas se acerca a la que propuso nuestro amigo
rapado (Oscar) pero adolece de algunos riesgos para mi gusto: no me gusta
mucho hostear worker threads en el proceso de ASP.NET, la escalabilidad es
limitada tambien (no por el limite de threads de ASP.NET sino por la
capacidad de proceso del server). Siembre es bueno que un web server tenga
mucho procesador disponible.

 

La solucion basada en MQ para el request y uno o mas procesadores en
paralelo es buena. Queda resolver la vuelta de la respuesta. Algunos
utilizar MQ tambien para la vuelta pero a mi no me gusta, prefiero volver
por una base de datos SQLServer para tomar el mensaje por ID en lugar de
escanear toda la cola de vuelta para buscar el mensaje (hasta donde se, MQ
no tiene una operacion eficiente para tomar un mensaje por ID). Igual, esto
seria importante solo en casos de muy alto caudal.

 

Abrazo

 

Carlos Peix

 

  _____  

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Diego
Jancic
Sent: Lunes, 03 de Diciembre de 2007 08:16 p.m.
To: [email protected]
Subject: [puntonet] Web service asincronico ?

Hola Oscar,

Pero entre enseñarle al programador a manejar ese WS con todos esos métodos
y enseñarle a hacer la llamada asincrónica (si es que no la sabe), no es mas
fácil la 2da?

Yo justo ahora estoy haciendo algo como lo que decis, envio pedidos (via
MSMQ) y hay N threads (prefijados por configuración) que procesan todas las
tareas… pero eso es por motivos muy particulares y (si esta todo dentro de
IIS) la carga no cambia en nada… Si usas un WS, o una pagina web IIS ya te
da la funcionalidad de tener multiples threads, una cola de mensajes en
espera, etc…

 

No es que quiera parecer muy negativo, pero me no lo veo eh.. J

 

Salu2!

 

 

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Oscar
Zárate
Sent: Lunes, 03 de Diciembre de 2007 07:28 p.m.
To: [email protected]
Subject: [puntonet] Web service asincronico ?

 

Agrego algo mas. 

El metodo IniciarTarea podría estar escribiendo los parametros de la
consulta en una Queue y del otro lado de la Queue podría haber N servidores
leyendo la Queue y tomando el requerimiento de la consulta (haciendo la
consulta y escribiendo en la table de resultados). 

 

Me gusta la idea ... me parece que me fui de mambo, pero me gusta.

 

SaludOZ,

 

PS: No creo ser muy original con esto, ya debe estar implementado mil veces
y seguro seguro seguro ... hay un patron con nombre para resolver esto.

 

On 12/4/07, Oscar Zárate <[EMAIL PROTECTED]> wrote: 

Yo creo que la idea sería escribir algo que responda "inmediatamente" o
responda ... "preguntame luego con este ticket.

 

No se cual es el negocio, pero me imagino algo que tenga mucho tiempo de
procesamiento ... entonces el web service tiene un metodo iniciar tarea (no
el proxy, el web service) este metodo inmediatamente retorna un ticket y
dispara un proceso y cuando finaliza el proceso guarda el resultado completo
en una tabla con ID igual al numero de ticket. Luego, otro metodo que recibe
el ticket y devuelve "resultado" o "preguntame luego". Este segundo metodo,
busca en la tabla si existe algun resultado para ese ticket, si existe
retorna el resultado, sino retorna "preguntame luego". 

Incluso la respuesta del proceso deberia ser formateada para que el metodo
que devuelve sea lo mas rapido posible (solo lee y retorna, no pierde tiempo
en ningun formateo).

 

De este modo, haces un "servicio" (sea web o no) que es "asincronico".
Incluso en el caso de una consulta MUY RAPIDA, la consulta completa consta
igual de una llamada a dos metodos.

 

Espero haber sido claro, creo que de ese modo solucionas el problema.
 

SaludOZ,
 

On 12/4/07, Diego Jancic <[EMAIL PROTECTED]> wrote: 

Hola,
Lo que no vas a poder hacer es que sea asincrónico desde el punto de vista
del cliente. El cliente (desarrollado por cualquier otra persona) se 
conecta, recibe una respuesta y ya esta, no podes hacer nada mas.
Lo que podrías hacer es trabajar dentro del web service para que no funcione
dentro de un thread de IIS, y asi sobrecargas menos al IIS.

Cuando decis "o que se comporte de alguna manera de atender muchas 
peticiones", no se bien a que te referis. Los WS están preparados para
recibir muchas peticiones, y si al usuario final le molesta que tarde tanto
(imaginemos que realiza un proceso largo, pero no se está sobre cargando el 
servidor del WS), es trabajo del que arma el cliente hacer que le aparezca
un hermoso "loading..."

Posiblemente la solución sea escribir un help para enseñarle a los otros
desarrolladores a hacer las cosas asincrónicas :) 

Saludos!


-----Original Message-----
From: [email protected] [mailto: <mailto:[email protected]>
[EMAIL PROTECTED] On Behalf Of Leonardo
Micheloni 
Sent: Lunes, 03 de Diciembre de 2007 05:55 p.m.
To: [email protected]
Subject: [puntonet] Web service asincronico ?

Entonces no te puedo ayudar, no tengo idea

On Dec 3, 2007 3:15 PM, Marcelo P < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
> Gracias por la respuesta
> El tema es que yo tengo que desarrollar un web service para que sea 
> consumido por cualquiera, yo no programo ni armo el proxy. Lo que tengo 
que
> hacer es que el web service sea asyncronico o que se comporte de alguna
> manera de atender muchas peticiones.
> Saludos 
>

 

 



__________ Información de NOD32, revisión 2699 (20071203) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com

Responder a