views:

59

answers:

3

My environment - C# 3.5 and ASP.NET 4.0 and VS 2010

Apologies - am a bit new to some of the concepts related to threading and Async methods.

My scenario is this:

  1. My site will periodically make a couple of GET/POSTS to an external site and collect some data
  2. This data will be cached in a central cache
  3. The periodic action will happen once in about 5 minutes, and will happen for every new member who registers on my site. The querying for the member will stop based on certain conditions
  4. The user does NOT need to be logged in for these periodic queries - they register on the site, and then off my async code goes - it keeps working 24/7 and messages the user once a while via email depending on certain trigger condition. So essentially it all should happen in the background regardless of whether the user is explicitly logged in or not.

Load Expected - I anticipate about 100 total running members a day (accounting for new members + old ones leaving/stopping).

the equation is ~ 100 visitors / day x 4 POST per fetch x 12 fetches / hour x 8 hours / day

In my mind - I'm running 100 threads a day, and each 'thread' wakes up once in 5 minutes and does some stuff. The threads will interact with a static central cache which is shared among all of them.

I've read some discussions on ThreadPools, AsyncPage etc - all a bit new territory. In my scenario what would you suggest? What's the best approach to doing this so it's efficient?

In your response I would appreciate if you mention specific classes/methods/links to use so I can chase this. Thanks a bunch!

+3  A: 

You will not be able to do it with ASP.net as such, you will not be able to keep the "threads" running with any level of reliability. IIS could decide to restart the appication pool (I.E. the whole process) at any point in time. Really what you would need is some kind of windows service that runs and makes the requests. You could the use HttpWebRequest.BeginGetResponse method to make your calls. This will fire off the relevent delegate when the response comes back and .net will manage the threading.

Ben Robinson
Ben, having a windows service is not an option. I am hosting this on a remote host with a basic hosting plan. I don't need the threads to be reliable - and I don't need absolute precision. But what I do need is continuous monitoring. Are you saying I can't have some kind of background processing running when no one is logged onto the site?
Gerry
ASP.net is not really designed for what you describe. You could try firing off some threads in the application_start event handler within global.asax if the security settings of your remote host may simply not allow this.
Ben Robinson
Ben, your answer got me thinking on the fundamental aspect of 'is that feature really important to my customer', and the answer is -- not really. Asking the user to keep a browser instance open and while I poll via a JS is 90% fine - so I think I'll stick to a simpler, cleaner and robust solution instead of overcomplicating ith with threads for a 'fancy feature' not really needed. Thank you - glad I asked the question first!
Gerry
+1  A: 
Jerzakie
A: 

You will need to create a separate Windows service(or a console app that runs using the Windows scheduler) to poll the remote server.

If you need to trigger requests based on user interation with your site, the best way is to use some kind of queuing system(eg MSMQ) that your service monitors.

geoff
Geoff - please see my comment to Ben above. Windows service or app is not an option. Thanks.
Gerry