C# – Getting a List of Users Currently Using an Application

From your description it sounds like your app performs a lot of DB and other network traffic. That is supposed to take magnitudes more time than executing the above code a few million times, be it in PHP or C#.

I would suggest you profile your app first, to see where the real bottlenecks are your app spends the most time, then focus on these areas. Typically, optimizing the way you query/update the DB (e.g. minimizing the number of roundtrips to the DB by performing batch updates instead of series of singular updates whenever you can) saves you way more time than any local processor time optimization.

Consider a exponential retry timeout

In the solution you've provided above having a retry mechanism every 1 second is naive solution.

You should consider a exponential time increase up to a maximum (decided by the business).

This is to avoid situations where you are spending valuable cycles on polling an ever increasing backlog of messages which will only fail and slowing down the processing of messages that can be handled and processed immediately.

Poisoned Messages

It is possible for poisoned messages to show up. These messages may never be able to be processed for one reason or another. You should consider having a process in place to identify and handle these messages.

This is a business decision, not an implementation detail

I think the most pertinent question is not what is said here, but what does the business want to do in this situation? How to actually create a retry polling mechanism is trivial. What the business wants to do in that situation is not, and is purely a business decision.

Real world example

I wrote a Distributed System for my employer a number of years ago (MSMQ, C#, etc). I implemented a system whereby messages would have a retry mechanism which would retry using an exponential function until it hit a max of once per hour.

I had a NAGIOS monitor in place which would poll and then detect number of failed messages in the queue and then push an alert if it reached a certain threshold. This would instantly alert the business that a vendor was offline and that clients who would be expecting a turnaround of lets say an hour.

It would then be a business decision (in this case the business decided to cancel all of these queued backlog of messages and then handle these manually via the helpdesk). And so the application had to be written to be able to allow manual processing of these messages.

In other instances where the vendor was only offline for a few minutes, the retry mechanism picked them up and handled them as per normal. However having the exponential timeout allowed the system to gracefully process regular transactions and the backlog without snowing the server under when the vendor came back online.