0

We are thinking of potentially using Service Fabric Actor Timers for a sort of TTL management service. It has the potential to have 100 hundreds of thousands of actor timers at time. We are concerned with the overhead of having this many actor timers running at a time but there does not seem to be any sort of documentation regarding actor timers their performance implications or underlying mechanisms. Any guidance would be greatly appreciated.

Tony
  • 1,297
  • 10
  • 17
  • Well, since actor timers [are just using regular timers](https://github.com/Azure/service-fabric-services-and-actors-dotnet/blob/develop/src/Microsoft.ServiceFabric.Actors/Runtime/ActorTimer.cs) it is not really service fabric/actor specific. – Peter Bons Jul 28 '17 at 07:47
  • They're more than just regular timers. They're built to respect the turn based concurrency of the actor that they're registered in. So there are definitely performance considerations depending on how much other traffic the actor is handling – Jesse Carter Jul 28 '17 at 14:18
  • @Jessie Carter The actors responsibility is only to alert when it TTLs and have the ability to be canceled. – Tony Jul 28 '17 at 14:27

1 Answers1

1

From what I know, Actor's Timer uses a lightweight 'System.Threading.Timer' under the hood, creating along a delegate that has a code to dispatch a call toward your 'wake-up' callback when the time comes. And seems like the dispatch happens just like any other incoming request would have, so I'd say that couple extra classes with a delegate are the cost of having SF Actor Timer.

Of course, if your need to perform a lot of work within the timer's callback then it will lock up your actor, so it also depends on how many requests will get blocked and how fast you could leave the callback.

Kiryl
  • 1,416
  • 9
  • 21