haproxy：高負荷下で既存のセッションを保持し、新しい到着に「503」を提供

タイトルに書かれていることをしようとしています。既存のセッションを高負荷で保持し、新しく到着した訪問者に503メッセージを提供します。

問題：動作しますが、セッションは約90秒以上持続しません。

現在の結果では、私が見逃しているタイムアウト設定があるかどうか疑問に思っています。

目的

私はhaproxyを取得しようとしています：

• フロントエンドのセッションの総数が特定のしきい値を下回ったときに、新しいセッションのリクエストをバックエンド-001に送信します。
• フロントエンドのセッションの合計数がそのしきい値を超えている場合、新しいセッションに503エラーを提供します
• セッション数がしきい値を超えた場合でも、既存のセッションの要求を許可します

このように、マルチステップフォームに入力しているビジターは503エラーに驚かないで、新しいビジターに「今忙しいので後で戻って来てください」と言うことができます。

セットアップ

セットアップは次のとおりです。

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

現在のアプローチ

上記を達成するために、以下の構成を使用しています。

これは、テストを簡単にするために、非常に低い制限（フロントエンドで10接続（fe_conn gt 10））でテスト用です。

サーバーに負荷をかけるために、次のようにhttperfを使用しています。

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

問題

上記のように、問題は次のとおりです。ほとんど機能しますが、セッションは約90秒以上持続しません。

クリックし続けると、10のセッションがビジー状態であってもセッションを維持できます。

別のブラウザインスタンスでサーバー上のページを開こうとすると、503エラーが発生します。

だから、私はほとんどそこにいるようです。短いセッション時間を引き起こしている可能性のあるアイデアは誰にもありますか？

そして特に私がそれを修正する方法:)

（編集：「サーバー」行から「重み1 maxconn 10」を削除しました。関連性がなく、混乱する可能性があります）

残念ながら、アプリケーションレベルのセッションとの接続は完全に混乱しているように見えます。サイトにアクセスするユーザーは、接続を所有していると思わせるCookieを持っている場合がありますが、必ずしもそうではありません。彼は、オブジェクトを取得してページをナビゲートするために必要な数の接続を開く可能性があります。

観察している90秒は、ブラウザのアイドル接続のキープアライブタイムアウトです。

目的を達成することは可能ですが、ビジターが新しいものであるかどうかを判断するためにリクエスト内の永続性Cookieの存在も考慮する必要があるため、それよりも少し複雑です。

また、一般に、フロントエンド接続カウントよりもサーバーごとの平均接続カウントに依存する方が効率的です。その理由は、サーバーが停止したときに、この数値を再調整する必要があるためです。最も効率的な方法は、サーバーのmaxconn値を設定してキューイングを有効にし、avg_queueを使用して、サーバー上のキューに入れられたリクエストの平均数に制限が適用されるようにすることです。これにより、既知の訪問者を正しく処理しながら、既存の訪問者のために負荷が増加したときに新しいユーザーを別のバックエンドにソフトに移動できます。