diff options
Diffstat (limited to 'docs/en/ranch/1.3/guide/internals.asciidoc')
-rw-r--r-- | docs/en/ranch/1.3/guide/internals.asciidoc | 94 |
1 files changed, 0 insertions, 94 deletions
diff --git a/docs/en/ranch/1.3/guide/internals.asciidoc b/docs/en/ranch/1.3/guide/internals.asciidoc deleted file mode 100644 index fa63f1d3..00000000 --- a/docs/en/ranch/1.3/guide/internals.asciidoc +++ /dev/null @@ -1,94 +0,0 @@ -== Internals - -This chapter may not apply to embedded Ranch as embedding allows you -to use an architecture specific to your application, which may or may -not be compatible with the description of the Ranch application. - -Note that for everything related to efficiency and performance, -you should perform the benchmarks yourself to get the numbers that -matter to you. Generic benchmarks found on the web may or may not -be of use to you, you can never know until you benchmark your own -system. - -=== Architecture - -Ranch is an OTP application. - -Like all OTP applications, Ranch has a top supervisor. It is responsible -for supervising the `ranch_server` process and all the listeners that -will be started. - -The `ranch_server` gen_server is a central process keeping track of the -listeners and their acceptors. It does so through the use of a public ets -table called `ranch_server`. The table is owned by the top supervisor -to improve fault tolerance. This way if the `ranch_server` gen_server -fails, it doesn't lose any information and the restarted process can -continue as if nothing happened. - -Ranch uses a custom supervisor for managing connections. This supervisor -keeps track of the number of connections and handles connection limits -directly. While it is heavily optimized to perform the task of creating -connection processes for accepted connections, it is still following the -OTP principles and the usual `sys` and `supervisor` calls will work on -it as expected. - -Listeners are grouped into the `ranch_listener_sup` supervisor and -consist of three kinds of processes: the listener gen_server, the -acceptor processes and the connection processes, both grouped under -their own supervisor. All of these processes are registered to the -`ranch_server` gen_server with varying amount of information. - -All socket operations, including listening for connections, go through -transport handlers. Accepted connections are given to the protocol handler. -Transport handlers are simple callback modules for performing operations on -sockets. Protocol handlers start a new process, which receives socket -ownership, with no requirements on how the code should be written inside -that new process. - -=== Number of acceptors - -The second argument to `ranch:start_listener/6` is the number of -processes that will be accepting connections. Care should be taken -when choosing this number. - -First of all, it should not be confused with the maximum number -of connections. Acceptor processes are only used for accepting and -have nothing else in common with connection processes. Therefore -there is nothing to be gained from setting this number too high, -in fact it can slow everything else down. - -Second, this number should be high enough to allow Ranch to accept -connections concurrently. But the number of cores available doesn't -seem to be the only factor for choosing this number, as we can -observe faster accepts if we have more acceptors than cores. It -might be entirely dependent on the protocol, however. - -Our observations suggest that using 100 acceptors on modern hardware -is a good solution, as it's big enough to always have acceptors ready -and it's low enough that it doesn't have a negative impact on the -system's performances. - -=== Platform-specific TCP features - -Some socket options are platform-specific and not supported by `inet`. -They can be of interest because they generally are related to -optimizations provided by the underlying OS. They can still be enabled -thanks to the `raw` option, for which we will see an example. - -One of these features is `TCP_DEFER_ACCEPT` on Linux. It is a simplified -accept mechanism which will wait for application data to come in before -handing out the connection to the Erlang process. - -This is especially useful if you expect many connections to be mostly -idle, perhaps part of a connection pool. They can be handled by the -kernel directly until they send any real data, instead of allocating -resources to idle connections. - -To enable this mechanism, the following option can be used. - -.Using raw transport options - -[source,erlang] -{raw, 6, 9, << 30:32/native >>} - -It means go on layer 6, turn on option 9 with the given integer parameter. |