sasl: overload. Or - “do not put more in the plate than it can accommodate”
Erlang is an excellent platform for building servers, and its standard library provides many tools that make life much easier for a developer.
One of the typical tasks of the industrial level server developer is to control the load. That is, our server must behave adequately even if requests come more than the server can handle (on our hardware).
This is actually one of the key differences between “knee” solutions and “Enterprise”. A real, well-designed server is “in the know” that it cannot spend resources without limit, keeps records of resources and controls the load.
')
How it's done?
One of the controls for loading into erlang programs is the overload module in the sasl application. His idea is very simple - with a new request from a client, we check the current download, if it is more than N per second, we send a polite refusal to the client. If the load is less than this threshold, then we transfer this request for the main processing.
The idea is simple - but the implementation is rather unpleasant, we must remember the time when the last few requests came, keep in mind that there may be local "peaks" of query intensity, etc.
Fortunately, the overload module does all this. In the program settings, you can specify the required threshold (roughly speaking in sys.config ), and then, when a request comes from the client, simply perform overload: request () and see the result — accept — continue work, reject — deny service.
That is something like
Behind the scenes - sasl counts when and how many times overload was called: request (), and based on this it considers the load using a complex formula (you can see it in the documentation), and decides whether the current request to process it is worth it.
How it looks in practice:
We configure sasl, approximately such sys.config:
Here we set the maximum intensity to 300 requests per second. We start, for example
erl + K true -sname rcvr -setcookie 123 -config sys.config
And follow the download. A week later, munin shows us this:
Here you can see that the server accepts and processes only 300 requests per second, which is what we needed.
The overload module is convenient, but not applicable everywhere because of its limitations. but in any case, to know and remember him is necessary.
One of the typical tasks of the industrial level server developer is to control the load. That is, our server must behave adequately even if requests come more than the server can handle (on our hardware).
This is actually one of the key differences between “knee” solutions and “Enterprise”. A real, well-designed server is “in the know” that it cannot spend resources without limit, keeps records of resources and controls the load.
')
How it's done?
One of the controls for loading into erlang programs is the overload module in the sasl application. His idea is very simple - with a new request from a client, we check the current download, if it is more than N per second, we send a polite refusal to the client. If the load is less than this threshold, then we transfer this request for the main processing.
The idea is simple - but the implementation is rather unpleasant, we must remember the time when the last few requests came, keep in mind that there may be local "peaks" of query intensity, etc.
Fortunately, the overload module does all this. In the program settings, you can specify the required threshold (roughly speaking in sys.config ), and then, when a request comes from the client, simply perform overload: request () and see the result — accept — continue work, reject — deny service.
That is something like
handle_call (SomeRequest, State) ->
case overload: request () of
reject -> {reply, overloaded, State}
accept -> {Result, NewState} = do_something (SomeRequest, State),
{reply, Result, NewState}
end.
Behind the scenes - sasl counts when and how many times overload was called: request (), and based on this it considers the load using a complex formula (you can see it in the documentation), and decides whether the current request to process it is worth it.
How it looks in practice:
We configure sasl, approximately such sys.config:
[
{sasl, [{overload_max_intensity, 300.0}, {sasl_error_logger, {file, "/ var / log / rcvr.log"}}, {utc_log, false}]}
].
Here we set the maximum intensity to 300 requests per second. We start, for example
erl + K true -sname rcvr -setcookie 123 -config sys.config
And follow the download. A week later, munin shows us this:
Here you can see that the server accepts and processes only 300 requests per second, which is what we needed.
Disadvantages overload
- Since sasl considers the intensity of overload: request () calls to determine the current load - overload: request () can be used only in one place in the program. You won’t get lost for a server that accepts (for example) http and rpc requests to configure overload separately for rpc and separately for http.
- Settings are set in sys.config (well, or in the .app file) and cannot be changed while the program is running. that is, to reconfigure sasl: overload, you will have to restart the server.
Morality
The overload module is convenient, but not applicable everywhere because of its limitations. but in any case, to know and remember him is necessary.
Source: https://habr.com/ru/post/117338/
All Articles