Servicio de tareas en segundo plano en un sitio de gran tamaño

https://softwareengineering.stackexchange.com/questions/13711

16-10-2019
|

Pregunta

Estamos lidiando con un problema interesante en StackOverflow.

Tenemos un montón de poco "se necesita hacer pronto-ish" tareas.Un ejemplo es la actualización de "Preguntas Relacionadas con" listas.Lo que hemos hecho en el pasado es piggy-back de esas tareas en algunos de los usuarios la carga de la página.

Esto nunca fue ideal, pero no era realmente notable.Ahora que ha pasado el 1.000.000 de signo de interrogación, los desafortunados usuarios están empezando a sentir.

La solución natural es en realidad impulsar estas tareas en segundo plano.Hay dos grandes maneras de hacer esto que me estoy planteando.

1.En IIS como una costumbre Hilo-Piscina/Trabajo-Cola

Básicamente, nos vamos a un par (noThreadPool, así , para no interferir con IIS) hilos y disponer de ellos de los servicios de algunas de las colecciones que estamos empujando Funcs en.

La gran ventaja aquí es la simplicidad.Que no tiene que preocuparse de cálculo de referencias de nada, ni tenemos que asegurarnos de que algunos externo de servicio y de responder.

También podemos tener acceso a todo nuestro código común.

La estafa es, también, que no debemos usar subprocesos en segundo plano.Las objeciones que yo conozco son todos centrado alrededor de hambre IIS (si utiliza ThreadPool) y los hilos de morir al azar (debido a AppPool de reciclaje).

Tenemos la infraestructura existente para hacer que el azar hilo de la muerte de un no-tema (es posible detectar una tarea ha sido abandonado, básicamente), y limitar el número de hilos (y el uso de la no-ThreadPool hilos) no es tan difícil tampoco.

~~Me estoy perdiendo cualquier otra de las objeciones en el proceso de IIS hilo de la agrupación/colas?~~

Se trasladó a StackOverflow, como realmente no fue abordado aquí.

2.Como un Servicio

Alguna solución de terceros, o uno personalizado.

Básicamente, nos gustaría organizar una tarea a lo largo de los límites del proceso a algún servicio, y simplemente olvidarse de él.Presumiblemente estamos conectando el código, o restringido a raw SQL + una cadena de conexión.

El pro es que es el "camino correcto" para hacer esto.

Los contras son que estamos muy limitados en lo que podemos hacer, o vamos a tener que resolver un sistema para el mantenimiento de este servicio en sincronización con nuestra base de código.También necesitaremos para enlazar todos nuestros monitoreo y registro de errores de alguna manera, que podemos obtener de forma gratuita con el "En IIS" opción.

Hay otros beneficios o problemas con el enfoque de servicio?

En pocas palabras, hay imprevistos y problemas insalvables que hacen de enfoque #1 inviable y si es así, ¿hay alguna buena terceros servicios que debe buscar la solución #2?

Solución

Un par de semanas atrás le pregunté a un pregunta similar en TAN.En una cáscara de nuez, mi enfoque para algún tiempo ha sido el desarrollo de un Servicio de Windows.Me gustaría utilizar NServiceBus (esencialmente MSMQ debajo de las cubiertas) a la jefa de las peticiones de mi web app a mi servicio.Yo solía usar WCF, pero conseguir que una transacción distribuida para que funcione correctamente a través de WCF parecía siempre como un dolor en el culo.NServiceBus hizo el truco, me podría confirmar los datos y crear tareas en una transacción y no te preocupes si mi servicio estaba en marcha y funcionando en el momento.Como un ejemplo simple, si alguna vez me necesitan para enviar un correo electrónico (por ejemplo, un correo electrónico de registro) me gustaría crear la cuenta de usuario y disparar una señal a mi Servicio de Windows (para enviar el correo electrónico) en una transacción.El controlador de mensaje en el lado del servicio, recoger el mensaje y el proceso que corresponda.

Desde ASP .NET 4.0 y AppFabric han sido liberadas, hay un número de alternativas viables para el mecanismo anterior.Refiriéndose a la cuestión que he mencionado anteriormente, ahora tenemos AppFabric AppInitialize(a través de la red.pipe) así como ASP .NET 4.0 Auto-Inicio que hacen que el desarrollo de los Servicios de Windows como web apps, una alternativa viable.He comenzado a hacerlo ahora por una serie de razones (la más grande de la implementación no es más un dolor en el culo):

Usted puede desarrollar una interfaz de usuario web sobre su servicio (ya que se ejecuta como una aplicación web).Esto es muy útil para ver lo que está sucediendo en tiempo de ejecución.
El modelo de implementación para su web en las aplicaciones de trabajo para su aplicación de servicio.
IIS proporciona un par de características para el manejo de errores de aplicación (similar en algunos aspectos a un Servicio de Windows).
Los desarrolladores Web están muy familiarizados con el desarrollo de aplicaciones web (de forma natural), la mayoría no sabe mucho acerca de las mejores prácticas al desarrollo de un Servicio de Windows.
Ofrece una serie de alternativas a la exposición de un API para otras aplicaciones que consumen.

Si usted va esta ruta (perdóname por copiar y pegar de mi post original) definitivamente, me gustaría considerar la posibilidad de ejecutar el fondo de la lógica de una aplicación web independiente.Hay varias razones para esto:

Seguridad.Puede haber un diferente modelo de seguridad para la interfaz de usuario muestra la información acerca de la ejecución de procesos en segundo plano.Yo no quiero exponer esta interfaz de usuario para cualquier otra persona, pero la ops equipo.También, la aplicación web se puede ejecutar como un usuario diferente que tiene un elevado conjunto de permisos.
Mantenimiento.Sería genial ser capaz de implementar cambios para el alojamiento de la aplicación de los procesos en segundo plano sin afectar el usuario que está usando el front-end del sitio web.
Rendimiento.Tener la aplicación separada de la principal sitio de procesamiento de las solicitudes de usuario significa que los subprocesos en segundo plano no va a disminuir IIS la capacidad para manejar la cola de peticiones entrantes.Además, la aplicación de procesamiento de las tareas en segundo plano podría ser implementado en un servidor independiente, si es necesario.

Haciendo esto nos lleva de nuevo al área de aspecto.WCF, NServiceBus/RabbitMQ/ActiveMQ etc., vainilla MSMQ, API RESTful (creo MVC) son todas las opciones.Si está utilizando Windows Workflow 4.0 puede exponer a un host extremo de que su aplicación web podría consumir.

El web hosting enfoque de servicios es todavía bastante nuevo para mí, sólo el tiempo dirá si fue la decisión correcta.Hasta ahora tan bueno, aunque.Por cierto, si usted no desea utilizar AppFabric (yo no podía porque por alguna extraña razón, Windows Server Edición Web no es compatible), la Auto-capacidad de arranque menciona en la Gu post funciona muy bien.Manténgase alejado de la applicationhost.archivo de configuración a pesar de que, todo lo que en ese post es posible la instalación a través de la consola de IIS (Editor de Configuración en el servidor principal de nivel).

Nota:Yo originalmente había publicado un par de enlaces más en este mensaje, pero por desgracia, este es mi primer post de este intercambio, y sólo en uno de los enlaces es compatible!Básicamente había dos otros, para obtener de ellos en Google "Muerte a los Servicios de Windows...Larga vida a AppFabric!" y "auto-start-asp-net-aplicaciones".Lo siento por eso.

Otros consejos

En realidad, hay una tercera forma en Windows para ejecutar servicios de fondo, y es muy común en el mundo de UNIX. La tercera vía es un CRON trabajo que ejecuta un pedazo de su infraestructura. En Windows esto se conoce como el task scheduler y es muy común para ejecutar código de forma programada. Para usar esto, crearía una aplicación de línea de comandos que se ejecuta en un horario prefinado. La ventaja de esto es que no tiene que preocuparse si el proceso se mantiene en funcionamiento como un servicio, porque si falla por alguna razón, se iniciará la próxima vez.

En cuanto a las tareas específicas de organizar, realmente solo necesita almacenar estas tareas en un almacenamiento binario persistente. Hasta que la aplicación de línea de comandos los elija del almacenamiento y los ejecute. He hecho esto en el pasado utilizando la base de datos de Cassandra como proveedor de estado de sesión para rellenar tareas de fondo para usuarios específicos en la base de datos de Cassandra, y luego hacer que la línea de comandos las elija y ejecutarlas para el usuario.

Es posible que esta no haya sido la solución de mariscal típica, pero funcionó muy bien para mí y resultó ser una solución muy elegante, porque las tareas programadas sobrevivieron a los cierres, problemas de red y cualquier máquina podría ejecutar la tarea ya que era centralmente almacenado.

Promoción desvergonzada, pero este es mi proyecto y la solución que solo detalla brevemente es por qué creé el proyecto:http://github.com/managedfusion/fluentcassandra/

Aplicación web CRON +

Este es un diseño probado en batalla que escamas horizontalmente junto con su granja web y se asegura de que esté utilizando el pila de tecnología web usted ya sabe.

Así es como funciona:

Cree un controlador/acción en su aplicación web para manejar tareas de fondo programadas. Por convención, generalmente llamo a la mía http://mydomain.com/system/cron.
Para la seguridad, esta acción debe bloquearse solo a direcciones IP autenticadas en la red local.
En una máquina separada, instale Wget y configurar un Tarea programada Para que WGet obtenga el recurso del paso 1. Puede hacer que la tarea se ejecute con la mayor frecuencia que desee (generalmente opto por 30 segundos). No olvide pasar el argumento de cookie apropiado a WGET para que se autentica a su aplicación web.
Para redundancia, también puede instalar un segundo WGet programado en una segunda máquina.

¡Hurra! Ahora tiene una ruta que se llamará cada 30 segundos. Y si la solicitud tarda 5 minutos en procesarse, a nadie le importará, porque no es parte de la solicitud de página de un usuario.

los cron La acción termina luciendo muy simple: tiene una lista de métodos para ejecutar en cierta frecuencia. Cuando entra una solicitud, ve si hay un método que necesita ser ejecutado y llama al método apropiado. Esto significa que puede controlar el horario en su base de datos., donde probablemente ya tenga muchos otros datos de configuración importantes para su sitio.

Más importante aún (para usted), esto significa que sus trabajos no tienen que ser llamados en un horario fijo. Puede escribir cualquier lógica que desee para determinar cuándo ejecutar un método.

Pros y contras

Pros

Ya eres muy bueno escribiendo el código ASP.NET MVC, por lo que esto te permite escribir tus tareas de fondo en el misma plataforma que escribes el resto de tu solución.
Las tareas se ejecutan en el mismo contexto que su aplicación web, por lo que puede Comparte el caché y hacer uso de métodos auxiliares que ya existe.
Si tienes que buscar un balanceado URI, entonces sus tareas de fondo ahora también están equilibradas.
Despliegue simultáneo - No tiene que preocuparse por sincronizar su aplicación web con su lógica de tareas de fondo, porque todos están en la misma implementación.

Contras

A lo largo de los años, algunas personas me han dicho que este diseño está "altamente acoplado", pero cuando se les presiona no han podido articular por qué es algo malo.

Nota: Si hay alguna pregunta o inquietud, Por favor agregue un comentario. Estoy feliz de elaborar.

He intentado y usado casi todas las formas posibles de hacerlo en mi aplicación actual. Comencé a hacer lo mismo que hace actualmente, de nuevo en una solicitud de usuario para llenar los datos y luego almacenarse en caché en el futuro. Me di cuenta de que esta también era una mala idea (especialmente a medida que escala a múltiples servidores web, más usuarios reciben el éxito).

También he tenido un trabajo programado que golpea una URL en la aplicación ASP.NET: esta es una solución decente, pero comienza a descomponer el momento en que escala más allá del servidor web.

Actualmente uso dos métodos diferentes, ambos usando cuarzo.net, que es una pequeña biblioteca excelente. El primero es Quartz.net que ejecuta en proceso con ASP.NET, está configurado en Global.asax y se ejecuta cada dos minutos. Utilizo esto para actualizar el caché ASP.NET fuera de la banda, que es la única razón por la que se ejecuta como parte de ASP.NET.

El segundo es que escribí una biblioteca para envolver cuarzo.net llamado Daemonmaster; hace que sea fácil dejar caer una DLL en un directorio y hacer que se ejecute en un servicio de Windows. Descubrí que ayuda a evitar algunas de las partes molestas de trabajar con un servicio de Windows y también limpia la API de cuarzo.net. Los servicios que se ejecutan a través de Daemonmaster son de dos sabores diferentes, los primeros son trabajos que necesitan funcionar todas las noches o cada X minuts. Los otros trabajos trabajan en una cola basada en datos que provienen de la aplicación ASP.NET. La aplicación ASP.NET deja deja objetos JSON en RabbitMQ y la encuesta de servicios RabbitMQ luego procesa los datos.

Según esto, le sugiero que vaya con un servicio de Windows (y consulte Daemonmaster) y, si es necesario, use una cola como RabbitMQ para pasar los datos de la aplicación ASP.NET a los Servicios: ha funcionado mejor de todas estas soluciones . Si está cargando caché, entonces ejecutar en ASP.NET tiene sentido, de lo contrario no creo que lo haga.

Daemonmaster: http://github.com/adzerk/daemonmaster
Quartz.net: http://quartznet.sourceforge.net/

Lo haría de la manera correcta y tendría un servicio de Windows que se ejecuta que monitorea una "cola". Digo "cola" porque la programación con MSMQ es similar a pegar a los pokers calientes en sus globos oculares.

Me he enamorado de la simplicidad de Retrasado :: trabajo en rieles, y algo similar podría hacerse fácilmente en .NET.

Básicamente agregas cualquier tipo de SomethingOperation (algo que tiene un Perform() método). Luego, solo sea serializar los parámetros relevantes, darle una prioridad, algún tipo de comportamiento de reintento predeterminado y meterlo en una base de datos.

Su servicio simplemente monitorearía esto y trabajaría los trabajos en la cola.

Hemos estado bastante contentos con un enfoque de Service Bus / Mensaje Queue / Service. La arquitectura básica es esta.

El sitio web envía un mensaje a la cola

bus.Send(new ProjectApproved()); // returns immediately

El servicio de Windows recibe y procesa el mensaje en su propio tiempo

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Do something "offline"
   }
}

La ventaja es que no hay retraso para el servicio frontal que los usuarios también están conectados. El servicio de Windows se puede cerrar y actualizarse sin interrupción en el sitio principal. Además es extremadamente rápido.

Si no puede almacenar todos sus datos dentro del mensaje, siempre puede almacenarlos y recuperarlos más tarde. Sugiero usar un mecanismo de almacenamiento de documentos como: Ravendb o Mongodb Donde es muy sencillo almacenar sus clases sin cambios.

El sitio web envía un mensaje a la cola

// Save your object
store.Save(completeProject);

// Send a message indicating its ready to be processed
bus.Send(new ProjectApproved() { ProjectId = completeProject.Id });

El servicio de Windows recibe y procesa el mensaje en su propio tiempo

public class DoesSomethingAwesome : ConsumerOf<ProjectApproved>
{
   public void Consume(ProjectApproved Message)
   {
      // Retrieve your object back
      var completeProject = store.Get(Message.ProjectId);
   }
}

Para simplificar las cosas, usamos: Rhino ESB y Topshelf. La configuración es extremadamente simple y establecer esto para una aplicación existente ha demostrado que lleva muy poco tiempo.

Tengo curiosidad por qué una combinación de los dos no es una opción viable. En este momento, activa trabajos en las vistas de la página, con un poco de SAP desafortunado que se atasca esperando 10 segundos para que surja la página. Al menos esa es mi comprensión de su método actual.

Sin embargo, esos trabajos tardan más y más en ejecutarse a medida que el sitio crece, y no desea descarrilar la experiencia del usuario en el sitio. Ni siquiera para unos pocos (o tal vez muchos) usuarios desafortunados durante todo el día, por lo que ahora está pensando en programar trabajos en segundo plano.

No veo por qué un trabajo de fondo se ejecuta a intervalos regulares no puede imitar a un visitante. Ahora no soy un programador de Windows, pero en el mundo de Linux configuraría un trabajo cron que se ejecuta a un intervalo regular, y tendría 2 líneas de código.

#!/bin/bash
wget -O /dev/null http://stackoverflow.com/specially_crafted_url

Combina los pros de ambos sistemas. Se hace en segundo plano. No efectiva a los usuarios. Todavía usa una vista de página para iniciar el trabajo. He visto este enfoque utilizado antes. Tiende a ser el punto medio entre las formas simples de las formas antiguas y las formas más complejas que avanzan en el camino.

Actualizar

Creo que puede evitar el problema de equilibrio de carga ejecutando los corredores de trabajo en los propios servidores web. El corredor de trabajo saca una URL de la cola de trabajo y la ejecuta así:

wget -O /dev/null http://localhost/specially_crafted_url

Debido a la naturaleza de las colas de trabajo/mensajería, los trabajos se distribuirán uniformemente entre los corredores de trabajo, lo que significa que el especialmente_crafteed_url finalmente se distribuye entre sus servidores web.

Creo que la estafa con el enfoque de servicio puro es que tiene un código disperso en el servicio y lejos de la aplicación central.

Esto es lo que hemos hecho con grandes antecedentes no sensibles al tiempo, que mantiene el código unido y simplifica el servicio:

Cree una cola de trabajos (ya sea en memoria o db, cualquier persistencia que sea necesaria para los tipos de trabajos)
Cree un servicio web que ejecute los trabajos en cola
Aplicación de servicio simple de Dead que llama al servicio web a un intervalo específico, deje todas las cosas complejas (recuperación de trabajo y ejecución) al servicio web en su base de código central.

Aún más simple, simplemente haga la llamada en una aplicación de consola y use el programador de tareas o VisualCron para convertirla en un "servicio".

Me gustó Topshelf. Mantiene la simplicidad, pero aún lo hace de la manera correcta como un servicio de Windows. Básicamente, cree una aplicación de consola, agregue aproximadamente 15-20 líneas de código, luego se instala como un servicio.

http://code.google.com/p/topshelf/

¿Qué tal tener un servicio de Windows muy simple que se ejecuta en el servidor web y golpea periódicamente una URL de mantenimiento que hace sus tareas misceláneas? Pídale que acelere la cantidad de trabajo que hace en cualquier solicitud dada.

Voy a reducir la tendencia aparente aquí y sugerir ir para el modelo en IIS. Lo he usado yo mismo y funciona muy bien. Realmente no es tan difícil implementar una clase decente de puso de hilo (a lo largo de los años, he extendido mi clase de grupo de hilos para apoyar la creación dinámica y la destrucción de hilos, volver a intentar los trabajos, etc.). Las ventajas son:

No hay servicio externo para monitorear
Simplicidad de la implementación: sin organización de procesos cruzados, sin monitoreo avanzado de trabajo
Todavía está dentro de su proceso IIS, por lo que puede hacer todo su registro habitual, etc. (sin necesidad de múltiples archivos de registro)
Implementación enormemente simplificada (cuando actualiza un servicio, debe detener el servicio, copiar los archivos, iniciar el servicio; esto se suma a sus actualizaciones habituales al código del sitio web)

En mi opinión, una solución en IIS es simplemente el "siguiente paso hacia arriba" de aprovechar el trabajo en vistas de página aleatorias.

Resquear es bueno. O incluso Kthxbye Si necesita ser notificado del valor resultante una vez que se complete.

Tanto Redis/Ruby.

Honestamente, si está haciendo un enfoque basado en servicios, realmente no necesita estar súper integrado con su plataforma actual, lo que creo que es una ventaja. Espero que pueda ser un sistema de configuración y forja que se ejecutaría (con el monitoreo de algún tipo) y los trabajos completos. No estoy seguro de que tenga que ejecutarse en la misma plataforma, ya que solo está actualizando/modificando la información de la base de datos.

Estoy bastante seguro de que podría salirse con la suya mucho más por mucho menos si cultivó este tipo de entidad separada, especialmente porque parece que está tratando con problemas de enhebrado. Ambas cosas Resquear y Kthxbye Mueva el procesamiento a procesos separados para permitir que el sistema operativo maneje la concurrencia.

Resquear

Kthxbye

Usaría un servicio WCF alojado escuchando una cola MSMQ.

Pro

Fire y olvide los mensajes de una manera desde la aplicación web
MSMQ/WCF Libring y reintento
Entrega garantizada; D
Gestión de letras muertas
Procesamiento distribuido
Fue / activación de MSMQ

Contras

MSMQ (no está muerto ... todavía)

Las características de MSMQ en WCF hacen que el uso de MSMQ sea realmente agradable. Sí, sangrará en la configuración, pero los beneficios superarán el sacrificio.

Me he encontrado con esto un par de veces al desarrollar aplicaciones web. Lo hemos estado resolviendo creando una aplicación de consola de Windows que lleva a cabo la tarea y creando una tarea programada que se ejecuta de vez en cuando para hacer la tarea.

Puede derivar el trabajo en un hilo de fondo (o muchos hilos de fondo) usando RX y algo como lo siguiente:

var scheduler = new EventLoopScheduler( SchedulerThreadName );
_workToDo = new Subject<Action>();
var queueSubscription = _workToDo.ObserveOn( scheduler ).Subscribe( work => work() );
_cleanup = new CompositeDisposable( queueSubscription, scheduler );

Usar:

var work = () => { ... };
_workToDo.OnNext( work ); // Can also put on error / on complete in here

Organice todo eso dentro de una clase que solo hay uno de (también conocido como un singleton, pero hágalo correctamente: use su contenedor IOC para determinar el estilo de vida).

Puede controlar el tamaño del grupo de subprocesos, etc., escribiendo un programador personalizado en lugar de usar EventLoopscheduler (que ejecuta un solo hilo).

He implementado este tipo de cosas varias veces. En Windows, configuré un programa de línea de comandos de Python que hace algo en varios momentos. Este programa también expone una interfaz XMLRPC en un puerto. Luego, un trabajo de tarea programada se ejecuta cada minuto y consulta las interfaces XMLRPC. Si no están despiertos, intenta lanzarlos. Si no puede, me envía un correo electrónico.

La ventaja es que el trabajo que se ejecuta no está atado al cron o en el horario. Tengo un trabajo de proceso que se ejecuta cada segundo, pero esperaré más y más tiempo entre comenzar un nuevo trabajo dependiendo de si tenía trabajo por hacer. Además, se puede usar para actuar de manera inteligente en función del resultado. ¿Tienes un error de 500? ¿Tienes un retraso realmente largo? Hacer algo más. Notificar otro servicio. Etc.

Y el mismo sistema funciona en UNIX, con modificaciones menores.

Yo no tengo una respuesta para ti, pero el problema hizo una campana, recuerdo a algunos chicos al azar Discutirlo en un podcast una vez.

Spolsky: Noté que una de las preguntas que hiciste en el blog era ¿cómo debía manejar tareas recurrentes de mantenimiento en general?

Atwood: Sí.

Spolsky: ¿Es esa una caracterización justa? Cada sitio web tiene algunas tareas que no desea ejecutar en el momento en que se está cargando una página web, pero desea ejecutar con alguna recurrencia de algún tipo.

Atwood: Ya, tareas de fondo.

Spolsky: Ya, ¿qué descubriste?

Atwood: Bueno, originalmente pregunté en Twitter, porque solo quería algo liviano. Realmente no me gustaba escribir un servicio de Windows. Sentí que eso estaba fuera del código de banda. Además, el código que realmente hace el trabajo es una página web de hecho, porque para mí esa es una unidad lógica de trabajo en un sitio web es una página web. Entonces, realmente es como si volviéramos al sitio web, es como otra solicitud en el sitio web, así que lo vi como algo que debería permanecer en línea y el pequeño enfoque que surgimos que me recomendó en Twitter Era esencialmente agregar algo al caché de la aplicación con una expiración fija, luego tiene una devolución de llamada para que cuando eso lo expira llama una determinada función que hace el trabajo, entonces lo agregue nuevamente al caché con el mismo vencimiento. Entonces, es un poco, tal vez "Ghetto" es la palabra correcta.

Descripción general de la API de Java de la cola de tareas

Conceptos de tareas
En el procesamiento de fondo del motor de la aplicación, una tarea es una descripción completa de una pequeña unidad de trabajo. Esta descripción consta de dos partes:

Una carga útil de datos que parametriza la tarea.
Código que implementa la tarea.

Tareas como ganchos web fuera de línea
Afortunadamente, Internet ya proporciona dicha solución, en forma de una solicitud HTTP y su respuesta. La carga útil de datos es el contenido de la solicitud HTTP, como variables de formulario web, XML, JSON o datos binarios codificados. La referencia del código es la URL en sí; El código real es cualquier lógica que el servidor ejecute para preparar la respuesta.

Haz ambos

Agregue un parámetro opcional a la ruta de preguntas que realiza el trabajo que actualmente está recurriendo en las solicitudes de usuario:

Servicio de tareas de fondo en un sitio grande

Cree una aplicación de consola que se ejecute en cada servidor y abra el registro de IIS compartido binario y la lee al final actual del archivo. Use un sistema de sistemas de archivos o un intervalo cronometrado para leer hacia adelante para recopilar actualizaciones a medida que IIS enjuagaba el registro.

Use esta información para determinar qué páginas se han visto actualmente.

Use las URL de la página del registro analizado para llamar a la versión "extrastuff" de la URL en localhost con un objeto WebClient.

Agregue algún código para cambiar de archivo al final de cada período de registro o reiniciar el proceso en cada período de registro.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a softwareengineering.stackexchange