I’m tasked to create a web application. I’m currently using c# & asp.net (mvc – but i doubt its relevant to the question) – am a rookie developer and somewhat new to .net.
Part of the logic in the application im building is to make requests to an external smsgateway by means of hitting a particular url with a request – either as part of a user-initiated action in the webapp (could be a couple of messages send) or as part of a scheduledtask run daily (could and will be several thousand message send).
In relation to a daily task, i am afraid that looping – say – 10.000 times in one thread (especially if im also to take action depending on the response of the request – like write to a db) is not the best strategy and that i could gain some performance/timesavings from some parallelization.
Ultimately i’m more afraid that thousands of users at the same time (very likely) will perform the action that triggers a request. With a naive implementation that spawns some kind of background thread (whatever its called) for each request i fear a scenario with hundreds/thousands of requests at once.
So if my assumptions are correct – how do i deal with this? do i have to manually spawn some appropriate number of new Thread()s and coordinate their work from a producer/consumer-like queue or is there some easy way?
Cheers
If you have to make 10,000 requests to a service then it means that the service’s API is anemic – probably CRUD-based, designed as a thin wrapper over a database instead of an actual service.
A single “request” to a well-designed service should convey all of the information required to perform a single “unit of work” – in other words, those 10,000 requests could very likely be consolidated into one request, or at least a small handful of requests. This is especially important if requests are going to a remote server or may take a long time to complete (and 2-3 seconds is an extremely long time in computing).
If you do not have control over the service, if you do not have the ability to change the specification or the API – then I think you’re going to find this very difficult. A single machine simply can’t handle 10,000 outgoing connections at once; it will struggle with even a few hundred. You can try to parallelize this, but even if you achieve a tenfold increase in throughput, it’s still going to take half an hour to complete, which is the kind of task you probably don’t want running on a public-facing web site (but then, maybe you do, I don’t know the specifics).
Perhaps you could be more specific about the environment, the architecture, and what it is you’re trying to do?
In response to your update (possibly having thousands of users all performing an action at the same time that requires you to send one or two SMS messages for each):
This sounds like exactly the kind of scenario where you should be using Message Queuing. It’s actually not too difficult to set up a solution using WCF. Some of the main reasons why one uses a message queue are:
And your requirements fit this like a glove. Since you’re already on the Microsoft stack, I’d definitely recommend an asynchronous WCF service backed by MSMQ.