Erlangはサーバーを構築するための優れたプラットフォームであり、その標準ライブラリは開発者の生活を大幅に簡素化する多くのツールを提供します。
産業レベルのサーバー開発者の典型的なタスクの1つは、負荷制御です。 つまり、（ハードウェアで）サーバーが処理できる以上の要求がある場合でも、サーバーは適切に動作する必要があります。
実際、これは企業の「ニーハイ」ソリューションの重要な違いの1つです。 リソースを無制限に使用することはできず、リソースの記録を保持し、負荷を制御する、「知っている」本物の適切に設計されたサーバー
これはどのように行われますか？
erlangプログラムをロードするためのコントロールの1つは、
saslアプリケーションの
オーバーロードモジュールです。 彼のアイデアは非常にシンプルです。クライアントからの新しいリクエストで現在の負荷を確認し、毎秒Nを超える場合、クライアントに丁寧な拒否を送信します。 負荷がこのしきい値よりも小さい場合、この要求をメイン処理に転送します。
アイデアは単純ですが、実装はかなり不快です。最後のいくつかのリクエストが入った時間を覚えておく必要があります。リクエストの強度のローカルな「ピーク」などがあるかもしれないことに注意してください。
幸いなことに、オーバーロードモジュールはこれをすべて行います。 プログラム設定で、必要なしきい値（大まかに言うと
sys.config ）を指定できます。その後、クライアントから要求が来ると、単に
オーバーロードを実行します
：request（）で結果を確認します-承認-作業を続行、拒否-提供を拒否します。
つまり、次のようなものです
handle_call（SomeRequest、State）->
ケースのオーバーロード：のリクエスト（）
reject-> {reply、overloaded、State}
accept-> {Result、NewState} = do_something（SomeRequest、State）、
{返信、結果、NewState}
終わり。
舞台裏-saslは、オーバーロードのタイミングと回数を考慮します：request（）が呼び出され、これに基づいて、複雑な式（ドキュメントを参照）に従って、負荷を考慮し、結果に基づいて、現在の要求が処理される価値があるかどうかを決定します
実際にどのように見えるか：
sys.configに近いsaslを構成します。
[
{sasl、[{overload_max_intensity、300.0}、{sasl_error_logger、{file、 "/ var / log / rcvr.log"}}、{utc_log、false}]}
]。
ここでは、1秒あたり300リクエストの最大強度を設定します。 たとえば実行
erl + K true -sname rcvr -setcookie 123 -config sys.config
そして、ダウンロードに従ってください。 1週間後、muninはこれを示します。
ここでは、サーバーが1秒間に300リクエストのみを受け入れて処理することがわかります。これが必要なことです。
過負荷の欠点
- saslはoverload：request（）の呼び出しの強度を考慮して現在の負荷を判断するため、オーバーロード：request（）はプログラム内の1か所でのみ使用できます。 httpやrpcリクエストを受け入れるサーバーが、rpcとhttpで別々に過負荷を設定する準備ができていません。
- 設定はsys.config（または、.appファイル）で設定され、プログラムの実行中は変更できません。 つまり、sasl：オーバーロードを再構成するには、サーバーを再起動する必要があります。
道徳
オーバーロードモジュールは便利ですが、その制限のために常に適用できるとは限りません。 しかし、いずれにせよ-それについて知って覚えることが必要です。