Web アプリケーションは現在あらゆる場所で使用されており、すべてのトランスポート プロトコルの中で HTTP が大きなシェアを占めています。 Web アプリケーション開発の微妙な違いを研究するとき、ほとんどの人は、これらのアプリケーションが実際に実行されるオペレーティング システムにはほとんど注意を払いません。 開発 (Dev) と運用 (Ops) の分離は、状況をさらに悪化させるだけでした。 しかし、DevOps 文化の台頭により、開発者はクラウドでアプリケーションを実行する責任を負うようになっているため、オペレーティング システムのバックエンドについて十分に理解することは開発者にとって非常に役立ちます。 これは、数千または数万の同時接続に対応するシステムを展開しようとしている場合に特に便利です。

Web サービスの制限は、他のアプリケーションの制限と非常に似ています。 ロード バランサーであれ、データベース サーバーであれ、これらすべてのアプリケーションは、高パフォーマンス環境では同様の問題を抱えています。 これらの基本的な制限と一般的にそれらを克服する方法を理解することは、Web アプリケーションのパフォーマンスとスケーラビリティを評価するのに役立ちます。

私は、知識豊富なシステム アーキテクトになりたい若い開発者からの質問に応えて、このシリーズの記事を書いています。 Linux アプリケーションの最適化テクニックを、オペレーティング システム レベルでどのように機能するかの基本を深く掘り下げずに明確に理解することは不可能です。 アプリケーションにはさまざまな種類がありますが、このシリーズでは、ブラウザやテキスト エディタなどのデスクトップ アプリケーションではなく、Web ベースのアプリケーションを取り上げたいと思います。 この資料は、Linux または Unix プログラムがどのように動作するか、および高パフォーマンスを実現するためにプログラムを構造化する方法を理解したい開発者およびアーキテクトを対象としています。

リナックスは サーバールーム オペレーティング システムであり、ほとんどの場合、アプリケーションはこの OS 上で実行されます。 私は「Linux」と言っていますが、ほとんどの場合、Unix に似たオペレーティング システム全般を意味していると考えていただいて問題ありません。 ただし、付属のコードを他のシステムでテストしたことはありません。 したがって、FreeBSD または OpenBSD に興味がある場合、結果は異なる可能性があります。 Linux 特有のことを試したときは、それを指摘します。

この知識を利用してアプリを最初から構築すると完全に最適化されますが、そうしないことをお勧めします。 組織のビジネス アプリケーション用に新しい Web サーバーを C または C++ で作成する場合、今日がその仕事での最後の日になる可能性があります。 ただし、これらのアプリケーションの構造を知っておくと、既存のプログラムを選択するのに役立ちます。 プロセスベースのシステムとスレッドベースのシステム、およびイベントベースのシステムを比較できるようになります。 Nginx のパフォーマンスが Apache httpd よりも優れている理由、Tornado ベースの Python アプリケーションが Django ベースの Python アプリケーションと比較してより多くのユーザーにサービスを提供できる理由を理解して理解できるでしょう。

ZeroHTTPd: 学習ツール

ゼロHTTPd は、教育ツールとして C で最初から作成した Web サーバーです。 Redis へのアクセスを含め、外部依存関係はありません。 弊社では独自の Redis プロシージャを実行しています。 詳細については、以下を参照してください。

理論について詳しく議論することもできますが、コードを作成して実行し、すべてのサーバー アーキテクチャを相互に比較すること以上に優れたものはありません。 これが最も明白な方法です。 したがって、プロセスベース、スレッドベース、イベントベースの各モデルを使用して、単純な ZeroHTTPd Web サーバーを作成します。 これらの各サーバーをチェックして、互いのパフォーマンスを比較してみましょう。 ZeroHTTPd は単一の C ファイルに実装されており、イベントベースのサーバーには以下が含まれます。 ウサッシュ、単一のヘッダー ファイルで提供される優れたハッシュ テーブルの実装。 他の場合には、プロジェクトが複雑にならないように、依存関係はありません。

コードには理解を助けるためのコメントがたくさんあります。 数行のコードで構成されるシンプルな Web サーバーである ZeroHTTPd は、Web 開発のための最小限のフレームワークでもあります。 機能は限られていますが、静的ファイルと非常に単純な「動的」ページを提供できます。 ZeroHTTPd は、高性能 Linux アプリケーションの作成方法を学ぶのに適していると言わざるを得ません。 一般に、ほとんどの Web サービスはリクエストを待機し、リクエストを確認して処理します。 これはまさに ZeroHTTPd が行うことです。 これは学習用のツールであり、生産用のツールではありません。 エラー処理が得意ではなく、セキュリティのベストプラクティスを誇っている可能性は低いです (そうそう、私は使用しました strcpy) または C 言語の巧妙なトリックですが、それがうまく機能することを願っています。

ZeroHTTPd のホームページ。 画像を含むさまざまなファイル形式を出力できます

ゲストブックの申し込み

通常、最新の Web アプリケーションは静的ファイルに限定されません。 これらは、さまざまなデータベース、キャッシュなどと複雑なやり取りを行うため、訪問者が自分の名前でエントリを残す「ゲスト ブック」と呼ばれる単純な Web アプリケーションを作成します。 ゲスト ブックには、以前に残されたエントリが保存されます。 ページの下部には訪問者カウンターもあります。

Webアプリ「ゲストブック」ZeroHTTPd

訪問者カウンターとゲストブックのエントリは Redis に保存されます。 Redis との通信には、外部ライブラリに依存しない独自のプロシージャが実装されています。 私は、公的に入手可能で十分にテストされたソリューションがある場合に、自作コードを展開することはあまり好きではありません。 ただし、ZeroHTTPd の目的は、HTTP リクエストの処理がパフォーマンスに重大な影響を与える一方で、Linux のパフォーマンスと外部サービスへのアクセスを調査することです。 各サーバー アーキテクチャで Redis との通信を完全に制御する必要があります。 一部のアーキテクチャではブロック呼び出しを使用し、他のアーキテクチャではイベントベースのプロシージャを使用します。 外部 Redis クライアント ライブラリを使用すると、このコントロールは提供されません。 さらに、この小さな Redis クライアントは、いくつかの機能 (キーの取得、設定、増分、配列の取得と追加) のみを実行します。 さらに、Redis プロトコルは非常にエレガントでシンプルです。 特別に教える必要もありません。 このプロトコルがすべての作業を約 XNUMX 行のコードで実行するという事実自体が、それがいかによく考えられているかを示しています。

次の図は、クライアント (ブラウザ) がリクエストしたときにアプリケーションが行う動作を示しています。 /guestbookURL.

ゲストブック アプリケーションの仕組み

ゲストブック ページを発行する必要がある場合、テンプレートをメモリに読み取るためのファイル システムへの呼び出しが XNUMX 回あり、Redis へのネットワーク呼び出しが XNUMX 回あります。 テンプレート ファイルには、上のスクリーンショットのページの HTML コンテンツのほとんどが含まれています。 コンテンツの動的部分（投稿や訪問者カウンター）用の特別なプレースホルダーもあります。 これらを Redis から受け取り、ページに挿入し、完全に形成されたコンテンツをクライアントに提供します。 Redis は増分時に新しいキー値を返すため、Redis への XNUMX 回目の呼び出しは回避できます。 ただし、非同期イベントベースのアーキテクチャを備えたサーバーの場合、多数のネットワーク呼び出しは学習を目的とした良いテストとなります。 そのため、Redis の訪問者数の戻り値を破棄し、別の呼び出しでクエリします。

サーバー アーキテクチャ ZeroHTTPd

私たちは、機能は同じですがアーキテクチャが異なる XNUMX つのバージョンの ZeroHTTPd を構築しています。

• 反復的
• フォークサーバー (リクエストごとに XNUMX つの子プロセス)
• Pre-forkサーバー（プロセスの事前フォーク）
• 実行スレッドを備えたサーバー (リクエストごとに XNUMX つのスレッド)
• 事前スレッド作成のあるサーバー
• アーキテクチャベース poll()
• アーキテクチャベース epoll

サーバーに HTTP リクエストをロードすることで、各アーキテクチャのパフォーマンスを測定します。 ただし、並列性の高いアーキテクチャを比較すると、クエリの数が増加します。 XNUMX 回テストし、平均を計算します。

テスト方法

ZeroHTTPd 負荷テストのセットアップ

テストを実行するときは、すべてのコンポーネントが同じマシン上で実行されないことが重要です。 この場合、コンポーネントが CPU をめぐって競合するため、OS には追加のスケジューリング オーバーヘッドが発生します。 選択した各サーバー アーキテクチャのオペレーティング システムのオーバーヘッドを測定することは、この演習の最も重要な目標の XNUMX つです。 さらに変数を追加すると、プロセスに悪影響を及ぼします。 したがって、上の図の設定が最適に機能します。

これらのサーバーはそれぞれ何をするのでしょうか?

• load.unixism.net: ここが実行場所です ab, Apache ベンチマーク ユーティリティ。 これにより、サーバー アーキテクチャのテストに必要な負荷が生成されます。
• nginx.unixism.net: サーバー プログラムの複数のインスタンスを実行したい場合があります。 これを行うには、適切な設定を備えた Nginx サーバーがロード バランサーとして機能します。 ab 私たちのサーバープロセスに。
• zerohttpd.unixism.net: ここでは、XNUMX つの異なるアーキテクチャでサーバー プログラムを一度に XNUMX つずつ実行します。
• redis.unixism.net: このサーバーは Redis デーモンを実行し、ゲストブックのエントリと訪問者カウンターが保存されます。

すべてのサーバーは同じプロセッサ コア上で実行されます。 考え方は、各アーキテクチャの最大パフォーマンスを評価することです。 すべてのサーバー プログラムは同じハードウェアでテストされるため、これが比較のベースラインになります。 私のテスト セットアップは、Digital Ocean からレンタルした仮想サーバーで構成されています。

私たちは何を測定しているのでしょうか?

さまざまな指標を測定できます。 さまざまな並列処理レベルでサーバーにリクエストをロードすることにより、特定の構成における各アーキテクチャのパフォーマンスを評価します。負荷は同時ユーザー数が 20 から 15 に増加します。

試験結果

次のグラフは、さまざまなアーキテクチャ上のさまざまな並列処理レベルでのサーバーのパフォーマンスを示しています。 Y 軸は XNUMX 秒あたりのリクエスト数、X 軸は並列接続です。

以下は結果を示す表です。

XNUMX秒あたりのリクエスト数

並行性
反復的な
フォーク
プレフォーク
ストリーミング
プレストリーミング
世論調査
エポール

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
–
380
2200
1800
2400
2250
2150

400
–
410
2200
1750
2600
2000
2000

500
–
440
2300
1850
2700
1900
2212

600
–
460
2400
1800
2500
1700
2519

700
–
460
2400
1600
2490
1550
2607

800
–
460
2400
1600
2540
1400
2553

900
–
460
2300
1600
2472
1200
2567

1000
–
475
2300
1700
2485
1150
2439

1500
–
490
2400
1550
2620
900
2479

2000
–
350
2400
1400
2396
550
2200

2500
–
280
2100
1300
2453
490
2262

3000
–
280
1900
1250
2502
大きな広がり
2138

5000
–
大きな広がり
1600
1100
2519
–
2235

8000
–
–
1200
大きな広がり
2451
–
2100

10
–
–
大きな広がり
–
2200
–
2200

11
–
–
–
–
2200
–
2122

12
–
–
–
–
970
–
1958

13
–
–
–
–
730
–
1897

14
–
–
–
–
590
–
1466

15
–
–
–
–
532
–
1281

グラフと表から、同時リクエストが 8000 を超えると、残っているプレイヤーは pre-fork と epoll の XNUMX 人だけであることがわかります。 負荷が増加すると、ポーリングベースのサーバーのパフォーマンスはストリーミングサーバーよりも低下します。 スレッド事前作成アーキテクチャは、epoll の競合相手となるに値します。これは、Linux カーネルが大量のスレッドをいかに適切にスケジュールするかを証明しています。

ZeroHTTPd ソースコード

ZeroHTTPd ソースコード ここで。 アーキテクチャごとに個別のディレクトリがあります。

ZeroHTTPd │ §── 01_iterative │ ├── main.c │ §── 02_forking │ §── main.c §── 03_preforking │ §── main.c §── 04_ threading │ §── main.c §── 05_prethreading │ §── main.c │ └── 06_poll │ §── main.c §── 07_epoll │ └── main.c §── Makefile §── public │ §── Index .html │ └── tux .png ━── テンプレート ── ゲストブック ────index.html

すべてのアーキテクチャ用の XNUMX つのディレクトリに加えて、最上位ディレクトリにはさらに XNUMX つのディレクトリ (public と template) があります。 XNUMX つ目には、index.html ファイルと最初のスクリーンショットの画像が含まれています。 他のファイルやフォルダーをそこに置くことができ、ZeroHTTPd はそれらの静的ファイルを問題なく提供するはずです。 ブラウザ内のパスがパブリック フォルダー内のパスと一致する場合、ZeroHTTPd はこのディレクトリ内でindex.html ファイルを探します。 ゲストブックのコンテンツは動的に生成されます。 ホームページのみがあり、そのコンテンツはファイル「templates/guestbook/index.html」に基づいています。 ZeroHTTPd は拡張用の動的ページを簡単に追加します。 ユーザーがこのディレクトリにテンプレートを追加し、必要に応じて ZeroHTTPd を拡張できるという考えです。

XNUMX 台のサーバーすべてを構築するには、次のコマンドを実行します。 make all 最上位ディレクトリから - すべてのビルドがこのディレクトリに表示されます。 実行可能ファイルは、起動元のディレクトリ内でパブリック ディレクトリとテンプレート ディレクトリを探します。

Linux API

この記事シリーズの情報を理解するために、Linux API に精通している必要はありません。 ただし、インターネット上には参考資料がたくさんあるので、このトピックについて詳しく読むことをお勧めします。 Linux API のいくつかのカテゴリについても触れますが、主にプロセス、スレッド、イベント、ネットワーク スタックに焦点を当てます。 Linux API に関する書籍や記事に加えて、使用されるシステム コールやライブラリ関数については mana を読むことをお勧めします。

パフォーマンスとスケーラビリティ

パフォーマンスとスケーラビリティについての注意点が XNUMX つあります。 理論的には、それらの間に関連性はありません。 応答時間が数ミリ秒で非常にうまく機能する Web サービスを作成することはできますが、まったく拡張できません。 同様に、応答に数秒かかる、パフォーマンスの低い Web アプリケーションもあるかもしれませんが、それは数万人の同時ユーザーを処理できるように数十倍に拡張できます。 ただし、高性能と拡張性の組み合わせは非常に強力です。 一般に、高性能アプリケーションはリソースを控えめに使用するため、サーバー上のより多くの同時ユーザーに効率的にサービスを提供し、コストを削減します。

CPU および I/O タスク

最後に、コンピューティングでは、常に I/O と CPU の XNUMX 種類のタスクが考えられます。 インターネット経由でのリクエストの受信 (ネットワーク I/O)、ファイルの提供 (ネットワークおよびディスク I/O)、データベースとの通信 (ネットワークおよびディスク I/O) はすべて I/O アクティビティです。 一部のデータベース クエリは、CPU に負荷がかかる場合があります (並べ替え、XNUMX 万件の結果の平均化など)。 ほとんどの Web アプリケーションは可能な最大 I/O によって制限されており、プロセッサーがフル容量で使用されることはほとんどありません。 一部の I/O タスクが大量の CPU を使用していることがわかった場合、それはアプリケーション アーキテクチャが貧弱であることを示している可能性が高くなります。 これは、CPU リソースがプロセス管理とコンテキスト切り替えに浪費されることを意味する可能性があり、これはまったく役に立ちません。 画像処理、音声ファイルの変換、機械学習などを行う場合、アプリケーションには強力な CPU リソースが必要です。 しかし、ほとんどのアプリケーションではこれは当てはまりません。

サーバー アーキテクチャの詳細を確認する

1. パート I: 反復アーキテクチャ
2. パート II。 フォークサーバー
3. パートⅢ。 プリフォークサーバー
4. パート IV。 実行スレッドを備えたサーバー
5. パート V. プリスレッドサーバー
6. パート VI。 POLベースのアーキテクチャ
7. パート VII。 epoll ベースのアーキテクチャ

出所： habr.com