| > Article suggests that a high performance framework is implemented
> where notification of a unavailability will be propagated "before
> real user tried to execute a request" (which would have 50% probability
> of happening if number of heartbeats per second would be equal to number
> of requests per second the service serves, ha ha). Yes and no. Sometimes there is a dependency that is used only on 1% of requests, or even 0.1% of requests. And that's thing thats hard to track by 50x error codes, because they are really rare. But anyway it's not "fully designed feature", just a vision of what potentially can be done. So it's not going to be a stumbling-block for implementation. > Also from the Article we can learn that sending a 304 with content does not work as expected (!?) Sending 304 works as expected. Passing arbitrary status code with arbitrary headers with arbitrary body from the application to a framework doesn't work as expected. > Not only that, but there should be only one connection to database,
> through all traffic will go. Pulling that up through a network switch
> connected to a server with multiple cables, or pushing all that through
> a single TCP connection, with a foot note that advises against rewriting
> it after a few years? Not sure I understand your question well. But note that I'm speaking about Python. We have many python processes on the box anyway. Each of them has it's own connections to the downstreams (i.e. a database). Then if we start writing asynchronous Python code, we need to send requests from multiple asynchronous tasks from each of the python process. I argue that it's more efficient to send requests from all tasks of a single process through a single downstream connection. > Also, everything explained there should run in a single thread,
> because surely it will be fast enough. Sure, single I/O thread in C will outperform any python processing of that data. That's true for 99.9% use cases. |