Multi-threading required in ASP.NET websites?

Question

I am building a simple ASP.NET website, which will receive SMSes via a 3rd party SMS API (through URL push), and then the website will acknowledge the senders by sending SMSes back to them. I am saving the incoming SMSes in a database. I have implemented the logic as below:

public partial class _Default : System.Web.UI.Page
{    
    protected void Page_Load(object sender, EventArgs e)
    {
     //declaring variables to be used elsewhere, but in this same class. I have just this one class.  
     //Grabbing the URL parameters here (contents of SMS). 
     //Saving SMSes in the database. Database interaction happening only inside Page_Load. 
      //Call these functions
      SomeLogicFunction();
      SendSMSFunction(); 
    } 

    SomeLogicFunction()
    {
    }

    SendSMSFunction()
     {
     }
}

Now, I have read somewhere that ASP.NET takes care of multi-threading and similar aspects. So, if I have a simple website like this, do I need to take care of multi-threading? Or Page_Load function/ASP.NET pretty much handles it automatically?

If the answer is I don't need to do anything, then its all awesome! But if I have to take care of multi-threading, can you please help with some tips on how should I approach? I expect few thousand SMSes.

Thanks.

"takes care of multi-threading and similar aspects" - that's very generic. ASP.NET allows multiple concurrent requests, but that does not mean, that it "takes care of multi-threading" - for example single request may require multiple threads, and ASP.NET is not responsible for that. — Giedrius, Jul 26 '12 at 05:51

score 3 · Accepted Answer · answered Jul 26 '12 at 05:51

By default, for each request that comes in, ASP.NET grab a thread pool thread, make a new instance of your Page class, and call the appropriate Page_Load and event functions on that thread. It will use multiple threads for multiple requests simultaneously. Just be careful that any state you have in static members and fields is being properly shared and synchronized. Of course, avoid the shared state if possible.

ASP.NET and IIS will begin to reject requests if there are enough requests already being processed, so make sure your processing times are sufficiently fast. If you run into bottlenecks, you can increase the number of requests happening in parallel. If you have really high load (say hundreds of requests a second), there are asynchrony APIs you can use to increase the number of in-flight requests even further. But start out simple, of course, and you'll probably be fine.

thanks for your help. I have not used any static variable, so I think I am good. Also, can you please clarify a bit on "If you run into bottlenecks, you can increase the number of requests happening in parallel." Any simple way to do that? or to check whether the website is running into bottlenecks? Thanks. — Dev Dreamer, Jul 26 '12 at 07:10
If you end up getting swamped, IIS/ASP.NET would start to fail requests, which should show up in the HTTP and event logs. I'd just be looking for those, which you are probably doing anyways. — Jason Malinowski, Jul 27 '12 at 04:36

score 0 · Answer 2 · edited May 23 '17 at 12:29

In this particular case I think you would benefit from using Multi-Threading in your ASP.Net application.

Let me explain first how Multi-threading works in ASP.Net

ASP.Net provides a fixed number of threads to be used to handle requests, when the max number of threads have been used, incoming requests will be placed in a queue blocking potentially the web application. If incoming requests keep arriving to the server, you would end up with a Service Unavailable error.

Therefore one simple way to increase scalability in your application is releasing ASAP the threads used by ASP.Net to handle your request.

A way to do this, is to create an Async page (you could also create an Async HttpHandler), when you create an Async page, the long-time consuming process is placed in another thread, releasing almost immediately the ASP.Net thread. When your process has finished, a new thread will be used to instantiate a new instance of your page (the whole page life cycle won't be run though, meaning this process is cheaper) and finally the response will be sent to your client.

As you can see, since you release your ASP.Net threads almost immediately new incoming requests can be handled by ASP.Net

As an example, consider the following answer:

https://stackoverflow.com/a/11525692/1268570

score 0 · Answer 3 · answered Jul 26 '12 at 06:14

The real question to ask in your case is that: Are the functions SomeLogicFunction() and SendSMSFunction() blocking or non-blocking? (i.e. do they block furthur code until the SMSes are sent or it resumes your Page_Load() processing while continuing to send messages asynchronously?

In case even one function blocks, then you will "have to" implement multithreading because you must create a separate thread for those functions to run parallelly while your Page_Load() processing is going on. OTOA, if they are non-blocking then ASP.NET will take care of them by running in separate threads if required or mandated by the framework.

Multi-threading required in ASP.NET websites?

3 Answers3