Hola Carlos Acabo de leer el articulo que mandaste, pero sigo opinando lo mismo.
Para los que no quieren leer todo el articulo, les resumo el ejemplo que utiliza. Hay 2 paginas: - slow.aspx: Hace un Thread.Sleep(2000); (ojo: no consume CPU, solamente mantiene ocupado al thread, por lo que es un caso distinto al de Marcelo) - fast.aspx: No hace prácticamente nada Y dice: - si ejecutas solamente fast.aspx podes hacer 52000 requests/minuto - si ejecutas fast.aspx y slow.aspx podes hacer 1000 requests/minuto Hay 2 temas por los cuales considero que el ejemplo del articulo no aplica a lo que pregunto marcelo. El primero es: - Con 52000 requests rapidos por minuto, estas incluyendo aquellos que usas para verificar el estado del proceso. (no son 52000 clientes, son N clientes preguntando muchas veces) - Con 1000 requests lentos por minuto, estas ejecutando realmente 1000 procesos utiles. (son 1000 clientes) La limitación de 1000 requests por segundo es porque IIS no esta creando mas threads, si se llega a este limite y hay CPU libre entonces se podrían agregar threads a IIS Incluso el articulo en un momento lo dice claro: If the slow pages in your application are sluggish due to intensive CPU usage, there is not much you can do about it except to throw in more hardware. If, however, the slow pages in your application are slow because they are waiting on non-CPU-bound operations to complete, then the problem is not the lack of CPU power, but the fact that slow requests are saturating the thread pool so that other requests must be queued until a thread is released. Lo unico que no me convence mucho de esta solucion es lo que dice despues en el articulo: If you can find the magic number that keeps your CPU utilization high and only delays or denies requests when the server is truly too busy to process more requests, you are very fortunate Me agote =P Abrazo!, Diego From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Peix Sent: Jueves, 06 de Diciembre de 2007 10:40 a.m. To: [email protected] Subject: [puntonet] Web service asincronico ? Va interlineado... _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Jancic Sent: Miércoles, 05 de Diciembre de 2007 06:38 p.m. To: [email protected] Subject: [puntonet] Web service asincronico ? Hola Carlos, Supongamos que el proceso tarde o temprano se corre dentro de IIS, con un thread creado por la aplicación, creado por IIS o por quien sea se ejecuta dentro de IIS. Quiero fijar esta ultima premisa, porque si el proceso se va a ejecutar en otro lado (seria lo optimo) cambian mucho las cosas [Carlos] De acuerdo... Ahora, si o si vas a necesitar 1 thread por cada proceso que quieras realizar (estoy suponiendo nuevamente que TODA la ejecución del proceso largo ocurre dentro de la misma PC) Entonces, si tu limite no esta en el procesador (el server es capaz de ejecutar NNN procesos simultaneos), porque los vas a crear vos a mano? No se si me logro explicar IIS esta diseñado para responder rápido por 2 razones: - En un caso normal la idea no es que el usuario espere 20 segundos una pagina - Si hay 100 usuarios conectados, y todos están haciendo procesos que duran 20 segundos, seguramente al servidor le esta saliendo humo [Carlos] La explicacion esta clara, sin embargo, hay que tener en cuanta algunos aspectos del diseño de ASP.NET. El grupo de threads que atiende peticiones externa es limitado y ese grupo atiende todos los requests, los lentos y los rapidos. Lo peor es que llega un punto en el que ya no tenes espacio para requests rapidos. Esto esta explicado en el articulo que coloco aqui abajo con mucha claridad. Fijate como ahi demuestra que el mismo IIS pasa de atender 52.000 requests por minuto en paginas rapidas a 1000 por minuto, cuando mezclas paginas lentas. Por este motivo, te conviene que las paginas ejecuten rapido. <http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx> http://msdn.microsoft.com/msdnmag/issues/03/06/Threading/default.aspx Pero en este caso, la aplicación va a recibir muchos requests largos que no van a matar al servidor (supuestamente), entonces es exactamente lo mismo decirle a IIS que cree y maneje los threads que hacerlo vos con a mano con ASP.NET Incluso en IIS6 (no se otras versiones), podes manejar cuantos threads se ejecutan por procesador en el servidor, podes monitorear el consumo de memoria por cada web garden, lo que permite reciclar un worker process sin que la aplicación deje de funcionar y seguramente muchas otras cosas que desconozco Lo que veo de bueno en tu solución y en parte me parece mucho mejor, es que es mas adaptable a cambios de funcionamiento (si cambia la forma de funcionar de la aplicación) Lo que veo mejor de configurar IIS solamente es que se hace en 2 minutos, y si despues hay que cambiar el método por algún motivo se hará otra cosa más complicada [Carlos] Cual es mi solucion? :-), ya me perdi... Saludos!, Diego From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Peix Sent: Miércoles, 05 de Diciembre de 2007 05:12 p.m. To: [email protected] Subject: [puntonet] Web service asincronico ? Hola Diego, no entiendo muy bien lo que decis. Los requests de ASP.NET son atendidos por una cantidad determinada de threads, automaticamente IIS (o http.sys en Win2k3) asigna un thread si hay disponibles. No estoy seguro de la cantidad de threads disponibles en cada una de las combinaciones (.NET 1.1 o .NET 2.0 sobre Win2000 o Win2003), pero asumamos que son 25 (o 100, como dice Pablo). Lo que es cierto es que una vez superado ese limite ASP.NET deja de atender requests (los encola), independientemente de que el procesado este en 5%. Esta situacion es la saturacion de thread pool. Otra cosa distinta es que vos inicies otros threads dentro del AppDomain de la aplicacion Web, en esto tenes el control vos y no interfiere con el pool que mencione antes. La unica desventaja que le veo es que consume procesador del server web y que estaas corriendo esos threads dentro de un proceso que puede desaparecer en cualquier momento (por reinicio de la aplicacion web por ejemplo). Carlos Peix _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Diego Jancic Sent: Martes, 04 de Diciembre de 2007 05:54 p.m. To: [email protected] Subject: [puntonet] Web service asincronico ? 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 __________ Información de NOD32, revisión 2699 (20071203) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com __________ Información de NOD32, revisión 2704 (20071205) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
