Highload web server with a large number of blocking threads operations?

Question

Highload web server with a large number of blocking threads operations?

Who know, explain, plz. There is, for example, unicorn or any other server.

As a rule, when configuring a server, specifies the maximum number of processes and workerb, T. O. multithreading falls entirely on the web server. In case when the query will occur blocking the flow of operation, it will block the flow entirely and it will not be available to new connections. Accordingly, if you have a limit of 2 flow and 2 user loaded them completely (which, of course, savagery for most web applications, but nevertheless), then new users will not be able to get answers to their queries while at least one of the threads is released. It is a fact. Just checked.

Django has a built-in server, which works without any brakes, it just creates a new thread for each request - nothing blocks, no restrictions, etc. In this case, multithreading rests entirely on the conscience of the system, where it will be free CPU time in the kernel and take the request (well, as I understand it). This is also evident from the experiment - do a bunch of queries, they in turn load different kernels.

QUESTIONS.

Why not a scheme to use in production? Why are all adamantly opposed to this approach and strongly recommend to set the number of processes and threads manually?

Ultimately, if the percent is downloaded, and the resources for the new thread will not. Even if it is still created, just the operation in this flow will have to wait for the CPU - it does not make the scheme less attractive if the distribution of queries across threads would be engaged in a web server.

In this and in the other case, the high load will result in large waiting times, or, as I understand it, if anything to limit media web server, it can simply reject overloade requests, but this is a dubious advantage, starting from the position that it is better to answer later than to answer.

Share your thoughts on the subject or advise normal books/articles that would not start with the words "I am not a professional in this subject, but..." or "this article does not claim anything, just..."

Thank you.

Wayne77 asked July 9th 19 at 12:53

Related questions

More answers about "Highload web server with a large number of blocking threads operations?"

3 answers

jaden_V answered on July 9th 19 at 12:57

Django has a built-in server, which works without any brakes, it just creates a new thread for each request - nothing blocks, no restrictions, etc. In this case, multithreading rests entirely on the conscience of the system, where it will be free CPU time in the kernel and take the request (well, as I understand it). This is also evident from the experiment - do a bunch of queries, they in turn load different kernels.

Also fierce, furiously leaking memory as soon as you somehow progresia.

Let the practical side. What problem so you are going to solve?

Just checked memory - run the benchmark on 10,000 new requests per minute. The value of the memory consumption stable, small. Memory consumption is on the conscience of the application itself. The problem outlined above. There's an app. Possible unexpected locking of threads. To give a hard limit - is fraught with brakes from other users. - Wayne77 commented on July 9th 19 at 13:00

OK, from the practical side. What a burden your real application. - Wayne77 commented on July 9th 19 at 13:03

: no, just the time of load testing :-) Decided to make a benchmark gunicorn configs with different - different types of workerb, different quantities, etc., to simulate a number of exception and the result I really did not like, decided to do reserch. - Wayne77 commented on July 9th 19 at 13:06

: Well what are you suggesting? of course gunicorn behind nginx? - jaden_V commented on July 9th 19 at 13:09

the result I really did not like -- in the Studio! - Wayne77 commented on July 9th 19 at 13:12

alternatively, try Uwsgi blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-n... https://ivan-site.com/2012/09/benchmark-uwsgi-vs-g... - jaden_V commented on July 9th 19 at 13:15

: Yes, nginx. Just uwsgi appears to be the same result as the standard jankovskaja servers.
The results (virtual car 2 cores, 2.6 GHz):

300 requests per second

gunicorn with standard synchronous worker (4 processes, 4 thread):
Average 1990 ms
Min/Max 407 / 4913 ms

increase the number of threads and processes made it worse
asynchronous type of worker increased the variation in response time

standard django server:
Average 270 ms
Min/Max 126 / 3697 ms

uwsgi (4 processes with 4 threads):
Average 149 ms
Min/Max 126 / 3278 ms

when the number of requests to 1000, all servers, in addition to the standard django started to give the 500th code in 50% of all queries. standard server gave Average 810 ms - jaden_V commented on July 9th 19 at 13:18

: this is regarding the load. here, in General all relatively normal. app calls to some endpoint performs ssh connections (library paramiko) (the question "why?" is beyond discussion xD). here begins the most interesting. in case of unavailability of the server on which it is necessary to reach, the stream freezes completely. to perform the operation asynchronously is not possible. in this case, if 4x4 = 16 such hang-UPS, new customers will not be processed. - jaden_V commented on July 9th 19 at 13:21

I saw this article. everything is quite subjective in relation to the features of the tested application. in a more standard form, with lightweight operations, almost all webservers give excellent results. in unusual situations you have to Excel. - Wayne77 commented on July 9th 19 at 13:24

Damion.Upt answered on July 9th 19 at 12:59

What do you mean by flows ? the operating system objects or objects of the internal representation of the system of execution of code ?
if the first - then not very well-creating/delete
if the second - that is called green processes (threads). Here is how the runtime itself is correct.
For example, Erlang can create millions of green processes and everything will fly as it should.

Why not very good to create/delete? - Wayne77 commented on July 9th 19 at 13:02

because it's the OS objects that are created\deleted hard. read about the Apache and why it is worse than nginx - Wayne77 commented on July 9th 19 at 13:05

samir39 answered on · Accepted Answer · 2019-07-09T12:55:10.519Z

Every tool has its purpose. We've all heard the popular phrase about nailing a microscope and chopping nuts with a hammer. The main feature of Django - fast and easy development. Multithreading in itself is not simple, and in Python even more. So Django is single-threaded and synchronous. Everything in it was designed for sequential execution and the attempt to make use of parallel will lead to problems. You can use his performance to mnohopocetny environment, but this is not a question to Django, and to the environment. For example, to uWSGI. To read about dynamic allocation of workarou in uWSGI you here. In the Django you should try to make view function quickly gave the result. Correctly their design so long and locking operations can be shifted to Celery. If the aim is to keep long and hard connect with the client, it is best to look to the side asynchronous frameworks Tornado, aiohttp or Gevent.