views:

77

answers:

4

Hi,

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

A: 

If you are working with SOAP, or some other type XML request, you may not have an issue dealing with the level of requests in a loop.

I set up something similar using a SOAP server with 4-5K requests with no problem...

cinqoTimo
+2  A: 

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:

  • There are a large number of messages to send;
  • The sending application cannot afford to send them synchronously or wait for any kind of response;
  • The messages must eventually be delivered.

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.

Aaronaught
made question a bit more specific
oklahoma_overlord
im gonna research msmq. meanwhile ill mark this as answer in recognition of your assistance
oklahoma_overlord
A: 

A SOAP request to a web service (assuming .NET 2.0 and superior) looks something like this:

WebServiceProxyClient myclient = new WebServiceProxyClient();

myclient.SomeOperation(parameter1, parameter2);

myclient.Close();

I'm assuming that this code will will be embedded into your business logic that you will be trigger as part of the user initiated action, or as part of the scheduled task.

You don't need to do anything especial in your code to cope with a high volume of users. This will actually be a matter of scalling on your platform.

When you say 10.000 request, what do you mean? 10.000 request per second/minute/hour, this is your page hit per day, etc?

Wagner Silveira
A: 

I'd also look into using an AsyncController, so that your site doesn't quickly become completely unusable.

Dave Cowart