CPU, memory usage, thread pool usage - ASP NET core Identity not confirmed mail users delete handling - In app or separate app?

user_7895803 0
Viewed 226

I'm wondering what is more suitable solution. I need to implement robot for checking and deleting unconfirmed registered users for e.g. 7 days after confirmation mail was sent. (If a user doesn't confirm his/her account I want to delete the user from database). I thought about 3 ways:

  1. implement a delegate in ASP NET core app directly and run it as an async task in a loop with a 24 hr sleep.
  2. create a console app which will run in loop with a 24 hr sleep
  3. create a console app which will be started by a third party software regularly (for example Cron or TaskScheduler)

Which of these ways will have the least impact for CPU and memory usage?
Also thread pool has limited amount to take, the more robots, the less threads for people trying to access my ASP net site, am I correct?
And my last question > is it a good idea to Thread.Sleep for such a long time? Something tells me it really isn't. On the other hand it's an ASP which will be running for months maybe years.

Anyway I love the vision of having all in one app (can be configured within one file and all starts at once). On the other hand something tells me it's not a super-great idea.

asp.net-identity asp.net-core c#
1 Answers

When the task is actually running I would expect the memory and process usage to be dominated by whatever is required for the task, and should be comparable for each method. So it should be more interesting to see the resource usage when it is not running.

  1. In process, using a timer (or an await Task.Delay(..) loop)

This would only require memory for the timer or the async state machine, and some additional memory for the code. This should fairly small, perhaps a few kilobytes. No processor time and no threads would be used while idle. This assumes that you do not hold onto any large data structures.

  1. In a separate persistent console process

This would use a few MB of memory for the .Net runtime, and some additional memory for code and data. In practice I would expect the memory to be paged to disk if the computer runs out of memory. No processor time would be used while idle.

  1. In a separate scheduled console process

This would only consume memory for the scheduler object, and this should be minimal. Obviously no processor time or threads would be used while idle.

Summary

scheduling a separate process would use the least resources. But all the methods should use fairly insignificant amount of resources while idle. So I would argue the choice should be made on other criteria, like what is easiest to maintain and/or deploy.

The thread pool will allocate more threads if needed. Threads should in general only be used when they are actually doing something (i.e. use await task instead of task.Wait() ), and you will have far more thread pool threads than you would have hardware threads. I would only be concerned about this if I observed a far higher number of threads than usual.

I would avoid Thread.Sleep if possible. A timer or await Task.Delay would usually be more appropriate.

user_123422380
Related