|
|
|
|
|
|
by mercurial
4082 days ago
|
|
|
> the issue is one thread was has too much work The underlying issue is that when you have a consumer-facing API which accepts HTTP requests with a body, the first thing you should think about is limits. > Consider the following - what if both processes got tied up? Do you just start another process? Would it feasible or wise to run 1000 processes (no it wont)? However this is a problem that you won't come across in Go by using goroutines and taking advantage of its scheduler, as you can easily run 1000s of goroutines performantly. I have no experience of go, but my understanding is that goroutines are green threads multiplexed over a small thread pool. If you get 5 MB of JSON in N different requests (N=number of cores) at the same time, I don't see go generating free CPU time out of thin air. The usual way to go about these things in a language without multithreading is to have a queue and a process pool, but this also won't magically solve the issue if all cores are busy. |
|
|
You don't, but the scheduler normally won't allow one thread to completely starve the cpu. Of course, its clear they should be using limits, however JVM, glibc threads scheduler or Go's green threads likely wouldn't allow a single thread to completely starve the CPU, eventually the scheduler will step in and divert resources to another thread.
Without limits in a threaded solution, you would see the latency increase, but you wouldn't see the application stop taking requests altogether.
However there are real benefits for having an event loop concurrency, so this shouldn't be taken as a reason one model is strictly better than another.