...
ウェブホスティングのロゴ

ウェブホスティングにおける接続制限：同時接続とサーバー負荷の最適化

接続制限 ウェブホスティングにおいて、遅延やエラーが発生する前にサーバーが確実に処理できる同時リクエスト数を制御する方法です。制限値、同時接続数、サーバー負荷の測定と最適化、およびターゲットチューニングによる確実な制御方法を具体的に紹介します。.

中心点

以下の要点は、この記事の内容と利点を簡潔にまとめたものである。.

  • 制限 同時接続は、過負荷やエラーメッセージから保護します。.
  • リソース CPU、RAM、I/Oなどが実効限界を決定する。.
  • チューニング Sysctl、Nginx/Apache、およびDBパラメータを使用すると、容量が増加します。.
  • モニタリング ボトルネックを早期に認識し、故障を防ぐ。.
  • スケーリング とキャッシュにより、トラフィックのピーク時のサーバー負荷を軽減する。.

接続制限とはどういう意味ですか？

接続制限は しきい値 新しいリクエストが拒否されたりキューに入れられたりする前に、ホストが受け付ける同時TCPコネクション数のこと。すべてのコネクションの背後には TCP-ハンドシェイク、バッファ、そしてリソースを消費する処理ユニット。制限がないと、システムはピーク時にすぐにタイムアウトしたり、„Connection refused“（接続が拒否されました）と報告したりする。カーネルとセットアップにもよるが、典型的な開始値は128から4096の間である。そのため私は、まずシステムが確実に処理できるオープン・ソケット、ファイル、プロセスの数をチェックし、負荷のピークを減らしつつ、正当なトラフィックを不必要にブロックしないような制限を設定することにしている。.

同時接続とサーバー負荷

すべてのオープン接続は リソース CPU、RAM、ネットワーク、そして場合によってはデータベースにおいて。高負荷時には、コンテキストスイッチが増加し、カーネルキューが一杯になり、サーバーは新しいリクエストの受け付けを一時停止する。Keep-Aliveはハンドシェイクを減らすが、長いタイムアウトの間、ソケットあたりのメモリ要件を増加させる。小さすぎるバックログ(SYNとAccept)は、アプリケーションの前でさえドロップにつながる。そのため、アクティブなコネクション、バックログの埋まり具合、再送を監視し、タイムアウトを最適化することで、アイドル時間を回避しつつ、使用後はコネクションを素早く解放するようにしている。.

パフォーマンス・チューニング

より多くの同時ユーザーのために、私はまずカーネル制限を引き上げ、次のことに同意する。 ネットワーク-バッファー。net.core.somaxconnパラメータは128であることが多く、新しいコネクションの受け入れを遅くするので、システムによってはかなり高めに設定する。net.ipv4.tcp_max_syn_backlogで半開きのコネクションのキューを増やし、ピークがきれいに通過するようにしている。受信バッファと送信バッファ(rmem_max, wmem_max)を帯域幅×RTTに調整し、ユーザースペースでパケットが詰まらないようにする。調整されたタイムアウトときれいな accept キューにより、安定的に処理されるリクエストの数は、私が 品質 レスポンスタイムに.

ウェブサーバーの設定Nginx と Apache

Nginxの場合、以下のようになります。 ワーカーコネクション また、worker_rlimit_nofile をシステムのリミットに合わせることで、 ファイル記述子のリミットが早期に衝突しないようにする。keepalive_timeout を約 1 分に設定することで、アイドル状態のソケットを長く保持することなく、コネクションを効率的にオープンし続けることができます。Apacheでは、Event-MPMとディメンションMaxRequestWorkersを使用して、RAMの予約がPHPプロセスのサイズと一致するようにしています。プリフォーク、ワーカー、イベント間のプロセスを深く理解することで、スループットに顕著な違いが出る。それぞれのモデルの長所については、以下を参照してください。 イベントMPMとワーカーモデル, これは、私が正しいアプローチを選択するのに役立つ。.

データベース接続とタイムアウト

データベースでは 最大接続数 そして、InnoDBバッファプールに十分なバッファを計画し、アクティブなレコードがRAMにあるようにしています。私はアプリケーションのキャンセル、ロック待ち時間、接続キューを監視しています。なぜなら、制限が高すぎると、アクティブなセッションが多すぎてCPUに負荷がかかりすぎるからです。コネクションがすぐにプールに戻されるように、トランザクションの継続時間とプールのタイムアウトを短くしています。一般的なウェブスタックでは、やみくもに上限を高くするよりも、適度に設定した値の方がはるかに効果があります。DBセッションが多すぎる場合の500のようなエラーパターンについてもっと深く掘り下げたい場合は、以下のサイトを参照してください。 データベース接続の制限, これはしばしば私の診断を早める。.

キャッシュ、HTTP/2/3とKeep-Alive

クリーン・キャッシュは動的なキャッシュを削減する 負荷 PHPとDBの呼び出しが少なくてすむからだ。ページキャッシュ、フラグメントキャッシュ、オブジェクトキャッシュは、アプリケーションにもよりますが、非常に大きな割合でデータベースへの負担を減らします。HTTP/2やHTTP/3では、ブラウザは多くのリクエストを少数のコネクションでバンドルするため、クライアントあたりのソケット数が劇的に減少する。圧縮（Gzip/Brotli）は帯域幅を節約し、CPUリザーブがある限り転送時間を短縮します。賢明なキープアライブタイムアウトを使えば、過度に長いアイドルフェーズでメモリを占有することなく、再利用されたコネクションから利益を回収することができます。 効率性 さらに増える。.

ハードウェアとネットワークのチューニング

同時使用率が高いユーザーには、次のようなメリットがある。 CPU-スレッド、RAM、高速NVMe SSDを使用することで、I/Oの待ち時間が短縮されます。16スレッドと64GBのRAMにより、大規模なピークをクリーンなレイテンシーで実行できます。ネットワークでは、特にBBRのような最新の輻輳制御を使えば、10Gbpsで十分です。バックグラウンドサービスを最小限に抑え、適切なI/Oスケジューラーを設定し、カーネルとドライバーを最新の状態に保っています。データ・ボリュームとログ・ボリュームを明確に分離することで、「ノイジー・ネイバー」効果を回避し、データ・ボリュームとログ・ボリュームを常に最新の状態に保つことができる。 応答時間 安定している。

PHP-FPM とプロセスの制限

多くのウェブサイトがPHP-FPMに依存している。 pm.max_children は、プロセス・サイズと使用可能なRAMに応じて設定される。高すぎる数値はRAMをブロックし、スワッピングを引き起こし、レイテンシーを大幅に増加させる。低すぎる数値は、CPU容量は利用可能だが、負荷のピーク時に503が発生する。私は、キューが短く保たれ、プロセスがスムーズに実行されるように、開始値、予備値、最大値を調整している。このモジュールの細かい点をより正確に設定したい場合は、以下のサイトで実用的なヒントを見つけることができる。 PHP-FPM pm.max_children, これにより、トラブルシューティングが大幅に簡素化される。.

モニタリングと負荷テスト

私は、次のような方法で永続的な安定を実現する。 モニタリング そして再現可能な負荷テスト。CPUの使用率、仮想環境でのステイルタイム、RAMクォータ、ディスクレイテンシー、ネットワークエラーを調べます。アクセプトキュー、SYNバックログ、再送信は、制限が厳しすぎるのか、アプリが遅くなっているのかを示す。負荷テストには、„hey “や „wrk “といったツールを使い、カーブの曲がり角を見つけるまでユーザー数を徐々に増やしていく。その上で、制限値を変更し、再度チェックし、その制限値を維持する。 安定性 現実的なパターンの下で。.

実用ガイド値と表

スタートコンフィギュレーションには 標準値, これは後で測定して微調整する。Nginxでは、worker_connectionsを2048から始めて、オープンファイルの上限を適切に高く設定することが多い。Apacheでは、イベントモデルを選択し、MaxRequestWorkersをPHPプロセスのサイズに合う範囲に保ちます。データベースでは控えめに開始し、レイテンシーが安定している場合のみ増加させます。カーネルリミットを上げてから、ピーク負荷でテストして 影響 キューと応答時間について。.

パラメータ コンポーネント 開始値 影響
net.core.somaxconn カーネル 4096+ 新規接続の受け入れ拡大
net.ipv4.tcp_max_syn_backlog カーネル 4桁の高値 半開きソケットでの落下を低減
rmem_max / wmem_max カーネル 帯域幅×RTT 高速ネットワークで混雑を防ぐ
ワーカーコネクション Nginx 2048 ワーカーあたりの同時実行数の増加
最大リクエストワーカー数 アパッチ（イベント） 150-400 RAM予算の管理プロセス
keepalive_timeout Nginx/Apache ~60s ハンドシェイクのオーバーヘッドを削減
最大接続数 データベース ~1000 セッションの負荷分散

オペレーティング・システムの制限：ディスクリプタ、ポート、ステート

明らかなネットワーク・パラメーターに加えて ファイル記述子 とプロセス制限は重要なパラメータです。私は、ウェブサーバー、PHP-FPM、データベースが十分なソケットとファイルを開けるように、ユーザーとサービスにnofile（ulimit）を設定している。カーネル全体の値fs.file-maxはこれと一致していなければなりません。そうでないと、サービスが正しく設定されているにもかかわらず、プロセスが早期に終了に達してしまいます。許可されるプロセス/スレッドの数 (nproc) も同様に重要で、負荷がかかった状態で予期しないフォークエラーが発生しないようにします。.

もう一度 エフェメラル・ポート (ip_local_port_range)やTIME_WAITのようなTCPステートを使用する。多数のアウトバウンド接続（プロキシやマイクロサービスなど）では、利用可能なポート範囲がボトルネックになることがある。攻撃的で安全でないカーネルスイッチを使うことなく、非アクティブなコネクションが素早く解放されるように、私は広い、賢明な範囲を選び、タイムアウトを設定する。重要なのは、アイドル時間を最小限に抑え、常に新しいコネクションを確立するのではなく、再利用（キープアライブ、HTTP/2/3、データベースプール）を促進することだ。.

リバースプロキシとロードバランサーのレベル

クライアントとアプリの間には、しばしば リバースプロキシ またはロードバランサーを使う。そこで、バックログ、タイムアウト、キープアライブも設定した。 上流-ページを参照してください。Nginxでは、アップストリーム・キープアライブ・プールがアプリケーションへの接続を確実に再利用し、ポートとCPUの両方の負荷を軽減します。私は、接続スロットリング(limit_conn)とリクエストベースのレート制限(limit_req)を、正当な負荷を抑制することなく個々のクライアントを制御するために使用しています。明確なエラーリターン（レート制限の503の代わりに429）は、運用中に原因を分析するのに役立ちます。.

時点では 接続プロセス デプロイ時やスケールダウン時には、コネクションドレインやグレースフル・シャットダウンを使っている。こうすることで、バージョンを入れ替えたりインスタンス数を減らしたりする際に、レイテンシーやエラー率が急増するのを防いでいる。.

TLS終了、HTTP/2/3の詳細とCPU使用率

TLSハンドシェイクにはCPUとレイテンシがかかる。可能な限りTLSを終了する クライアントの近く (例えばエッジプロキシで) セッション再開、OCSPステープリング、最新の高性能暗号スイートを使用する。これはハンドシェイクを節約し、time-to-first-byteを短縮する。HTTP/2/3では、ヘッダー圧縮と優先順位付けに注意を払う価値がある：優先順位付けが不適切なストリームは、同時性が高くても遅延を増大させる可能性がある。私はまた、キープアライブタイムアウトとオリジンごとの制限が、行頭ブロッキングが起こらないように選択されていることを確認する。.

特にCPUに負荷のかかる暗号やブロトリ・レベルでは、ベンチマークを使って圧縮のポイントを見つける。 ブレーキの代わりに使用. .ピーク時には、CPUがボトルネックになるため、一時的に圧縮レベルを下げ、通常のトラフィックの時にはまた上げる。.

リアルタイム・トラフィック：WebSocket、SSE、ロング・ポーリング

長時間開いたままのコネクション（WebSocket、サーバーから送信されるイベント、長時間のポーリング）は、キャパシティプランニングに強い影響を与える。このような 長寿-コネクションを従来のリクエスト/レスポンスパスから変更し、専用ワーカーを増やし、制限を厳しくする。接続ごとに必要なリソースが少ないことが重要である：ここでは、軽いプロトコルスタック、タイトなバッファ、保守的なキープアライブ戦略が必須です。接続の種類別に測定することで、古典的なページビューが恒久的な接続に悩まされないようにしています。.

コンテナとクラウド：Conntrack、ポッドの制限とウォームアップ

コンテナ環境では、私はしばしば次のような問題に直面する。 コンントラック-nf_conntrack_max とハッシュ・サイズは、予想される接続数と一致しなければなりません。そうでないと、パケットはカーネル内ですでにドロップしてしまいます。Podリミット（CPU/Memory Requests & Limits）は、インスタンスが実際に管理できる同時リクエスト数も決定します。起動したてのポッドがフル・トラフィックを受ける前にキャッシュを満たすことができるように、ウォームアップ・フェーズをスケジュールします。ノードレベルでは、ulimitとsysctlの値がコンテナに届き（initContainerやDaemonSets経由など）、ホスト上でスタックしないようにします。.

時点では 水平スケーリング CPUだけでなく、P95/P99のレイテンシーもトリガーとして使っている。こうすることで実際のユーザー体験に反応し、個々の „うるさい “ポッドが平均を歪めるのを防いでいる。Ingress/Serviceのコネクション・ドレインは、スケールアップやスケールダウン時のスムーズな移行を保証する。.

エラー画像と迅速な診断

私は典型的な症状を明確なパターンで認識している：

  • 再送/SYNドロップが多い： バックログが少なすぎる、パケットロスやアクセプトキューが短すぎる。.
  • 502/504が多い： アップストリームのタイムアウト、PHP FPM/DB プールが小さすぎる、またはアプリケーションの呼び出しがブロックされている。.
  • 503 負荷がかかっている： ワーカーまたはプロセスプールが枯渇した、RAMの制限に達した、制限が厳しすぎる。.
  • TIME_WAITのスパイク： 再利用の代わりに過剰な新設。キープアライブ／プーリングをチェックする。.
  • 安定したp50で増加するp99のレイテンシー： 待ち行列効果、ホットスポット、ロック競争。.

については 迅速な診断 メトリックス（バックログ、接続状態、レイテンシー）と短いプロファイリングやログサンプルを組み合わせている。I/Oがボトルネックにならないように、アクセスログをバッファリングまたは選択的に書き込みます。ログがボトルネックになった場合は、非同期でログを移動させ、一元的に集計している。.

キャパシティプランニング：ヘッドルーム、SLO、テストプロファイル

と計画している。 ヘッドルーム 典型的な1日の負荷より20～40%高いので、短時間のピークでもすぐに限界に達することはありません。ビジネスクリティカルなアプリケーションの場合、N-1リザーブを実行します。1つのインスタンスに障害が発生しても、残りのインスタンスのキャパシティは許容可能なSLOには十分です。私は測定可能なターゲット（例えば、300ミリ秒未満のリクエスト99%、エラー率0.1%未満）を定義し、それに対してテストします。.

私は負荷テスト中にプロファイルを切り替えている：

  • ステップロード： キンクポイントをはっきり見るために、1～5分刻みで増やす。.
  • 浸漬テスト： リークとドリフトを検出するため、一定の高負荷下で数時間。.
  • バーストテスト： 短期的なピークをシミュレートし、バックログのリザーブとリミットを検証する。.

私はスループットを測定するだけでなく 待ち行列での待ち時間, VMのCPUスティール、ディスクレイテンシー、ネットワークエラー。システムがシステム的に安定しているのか、それとも短期的に速いだけなのかを示すのは、その組み合わせだけである。.

スケーリングとトラフィックのピーク

突発的なピークには ロードバランシング, キャッシュとコンテンツのアウトソーシング。ラウンドロビン方式やウェイト方式は、複数のインスタンスにリクエストを分散させる。静的ファイルをCDNにプルすることで、オリジンサーバーのCPUを動的レスポンス用に空ける。アプリケーションやコンテナレベルでのオートスケーリングは、これらの手段を補完し、ロードジャンプに対するレスポンスタイムを短縮する。クォータとレート制限を使って、バックログの洪水からプラットフォームを保護し 空室状況 高い。

私の核となるロードマップ：これが私の進め方だ

まず、電流を測定する。 制限, レイテンシー、エラーレート、キューの長さを測定し、ハードボトルネックを記録する。その後、カーネルとウェブサーバーの制限を徐々に引き上げ、キープアライブとバッファを調整し、負荷がかかったときの効果をチェックします。第3段階では、キャッシュを統合し、HTTP/2またはHTTP/3を有効にし、データベース・パラメーターを最適化する。4番目のステップでは、PHPのFPMプロセスとファイル記述子の制限をRAM予算と調和させます。最後に、常時監視を確立し、定期的に負荷テストを繰り返し、こうして 接続 リミットは恒久的にグリーンレンジにある。.

結論：ギリギリの状態ではなく、リザーブで安定している

コネクション・リミットは単一のスイッチではない。 交流 カーネルのキュー、ウェブ・サーバーの設定、プロセス・プール、データベースのチューニング、ネットワーク・パス、ハードウェアなどだ。単独で制限値を上げても、問題を先送りするだけであることが多い。そのため、私は総合的なアプローチを取っています。まず測定し、次にターゲットを絞った方法で増加させ、常に実際の負荷パターンに照らし合わせてテストし、モニタリングでバックアップします。こうすることで、スループットと信頼性が共に向上し、ピーク負荷時でもサーバーは安定した状態を保つことができます。 予測可能なパフォーマンス.

現在の記事