The essence of the question is this. There is a class, in it the function of sending a message from WebRequest in a separate thread with an infinite loop, with a delay of 1 second. We create an array of this class, for example 10 elements. Cycle through the array, then run on the endless sending of messages. And the more elements in the array, the longer will be sending. Although, if you do not make an array, but run different copies of the program, then sending messages will be instant. I will attach the abstract code below.

class Request { public void Start() { new Thread(()=>{ while(true) { SendRequest(); Thread.Sleep(1000); } }).Start(); } } public Main() { var requests = new List<Request>(); requests.Add(new Request()); foreach(var request...) { request.Start(); } } 
  • 2
    1) try sending requests asynchronously 2) use HttpClient - tym32167 to send
  • 2
    By the way, it turns out that you generate a bunch of threads, and the more threads, the slower the program works. I will explain - in a multithreaded application, switching between threads is an expensive operation in terms of resources and time. Thus, the more threads - the more switching between threads, the more time is spent on switching and less on useful work. In other words, if you create a lot of threads, your program will not run faster, but most likely it will just hang, since all the time it will be spent on switching between threads. - tym32167
  • 2
    The thing is that now, when you create 100,500 threads, most of the time each thread either waits for a response from the server, or waits for Thread.Sleep () - that is, in fact, stands idle. If you redo it into asynchronous requests, then you don’t understand a lot of threads, since an asynchronous operation doesn’t take a thread at all. And once there are fewer threads, then less switching between them, and, as a result, everything should work faster - tym32167
  • one
    @ tym32167 why not the answer? - rdorn
  • one
    @rdorn added a response - tym32167

2 answers 2

It turns out that you generate a bunch of threads, and the more threads, the slower the program works. I will explain - in a multithreaded application, switching between threads is an expensive operation in terms of resources and time. Thus, the more threads - the more switching between threads, the more time is spent on switching and less on useful work. In other words, if you create a lot of threads, your program will not run faster, but most likely it will just hang, since all the time it will be spent on switching between threads.

The thing is that now, when you create 100,500 threads, most of the time each thread either waits for a response from the server, or waits for Thread.Sleep () - that is, in fact, stands idle. If you redo for asynchronous requests, then you don’t understand a lot of threads, since an asynchronous operation doesn’t take a thread at all. And once there are fewer threads, then fewer switches between them, and, as a result, everything should work faster.

That is, you need to:

  • Try sending requests asynchronously.
  • use to send an HttpClient

As an example (I cannot vouch for correctness - I did not launch it, but the idea should be clear)

 public class Request { private bool _runned = false; public async void Start() { _runned = true; while(_runned) { await SendRequest("http://google.com"); await Task.Delay(1000); } } public void Stop() { _runned = false; } private static async Task<string> SendRequest(string url) { using(var client = new HttpClient()) { var result = await client.GetStringAsync(url); // do smthg return result; } } } 

    In my opinion, since version c # 4.0, we recommend using the Task class, and not Thread. Task will use threads from the thread pool. In short, the pool is optimized for thread allocation.

    • one
      Task будет использовать потоки из пула потоков - this is not entirely true. This, firstly, depends on how the task is created. Secondly, tasks may not use threads at all. A task is such an abstraction of a piece of work, and how it is performed is hidden inside the task. - tym32167
    • one
      If you use the standard Task.Run () or Task.Factory.StartNew () then the pool will be used. The remaining cases are very rare (never saw a samopini task scheduler). Well, the result from Taska can be returned immediately, then the stream will not be used, but this is also a rare case. - Vadim Bondaruk
    • one
      The Task.Factory.StartNew() method contains many parameters, you can explicitly specify that the task needs a separate thread, or you can even transfer your scheduler. But this is not important, because here the client itself supports asynchronous operations and it is not necessary to create tasks manually. Look at my answer - I have never created a task anywhere, but they exist. - tym32167
    • one
      I completely agree with you, I just wanted to explain to a person that using thread is not very good. And in its code, Thread.Start can be replaced by Task.Run - Vadim Bondaruk
    • one
      Unfortunately, this will not help either, since by putting a lot of tasks to the thread pool, the pool will not perform them all at once, but will do it in batches in turn, which will also work slowly. The best option is not to use either threads or a pool of threads, but wait for responses from the server asynchronously. - tym32167