テストタスクとしてのWebServer

それがすべて始まった方法

現在の私の仕事はデスクトップアプリケーションに関連しているという事実にもかかわらず、私は最近「サーバーテクノロジー」に興味を持っています。 インターネットをサーフィンしたり、man'ovを読んだり、自分用にサーバーのようなものを書き込もうとしたりする人もいます。明確な目標がないため、これが最近行われたすべてです。 おもしろいタスクを思いついたら、あなたのスキルレベルをそれほど悪くはしないでください。



仕事から退屈になったある時点で、よく知られている求人検索リソースの1つをチェックしました。市場を見るのは気にしないことです。突然、興味深いことが浮かび上がります。 「おそらくあなたに興味があるでしょう。」 そのような提案の中で、テストタスクを伴う提案が来ました。 テストタスクは、HTTPプロトコルの実装を使用して、LinuxでC ++でWebServerを作成することです。 気取らない...



テストタスクのフレーズをGoogleに導入したところ、 RSDNフォーラムで最短のテストタスクではなく、これに関するレビューを見つけました。 タスクは、私のメーラーにある1対1でした。 割り当てとして、彼はしませんでした。 原則は単純です。テストタスクに価値がある場合は、4時間以内の作業時間で設計する必要があります。 しかし、読み聞かせられ、場所で試されたすべてを試すことは興味深いことでした。 これがインセンティブになりました。 興味深い問題の声明。 採用担当者からのものであるため、このタスクがどのオフィスに属しているかは言えませんが、それほど重要でもありません。



この記事では、このトピックで見つけたアプローチと関連APIを調べます。 さまざまなアプローチとツールを使用してWebServerのいくつかの実装を提供し、受け取った「クラフト」の比較テストを実施しました。 この記事は「ひげを生やした」サーバーライターを対象とはしていませんが、レビューとして（テストだけでなく）同様のタスクに遭遇する人が役に立つかもしれません。 記事を書くことは経験を共有することだけでなく、それを自分で補充することになるかもしれないので、私はみんな、特に「ひげを生やした」サーバーライターから建設的なコメントをうれしく思います...

APIとライブラリの概要

サーバー側のスクリプトツールを検討した結果、API * nix of systems、Windows API（このプラットフォームはこのタスクの目的ではありませんが、表示されません）、およびboost.asioやlibeventなどのライブラリがありました。



Berkeleyソケットは 、普遍的でポータブルなメカニズムですが、完全に明確に移植されているわけではありません。 そのため、一部のプラットフォームではソケットを閉じるために近く、一部のクローズソケットでは。 ライブラリを初期化する必要があるもの（Windows-WSAStartup / WSACleanup）、そうでないものもあります。 どこかでは、ソケット記述子はint型で、どこかではSOCKETとその他の小さな違いです。 pImplなどのすべての種類のクロスプラットフォームプログラミングアプローチを適用しない場合、同じコードは機能せず、多くの場合、異なるプラットフォームで同じ方法でビルドされます。 これらの小さなものはすべて、 boost.asio 、 libeventなどのライブラリに隠されています。 さらに、このようなライブラリは、対応するプラットフォームのより具体的なAPIメソッドを使用して、ソケットを使用した最適な作業を実装し、プラットフォームのヒントなしに便利なインターフェイスをユーザーに提供します。



サーバーの作業を非常に一般化した方法で実行すると、次の一連のアクションが発生します。

1. ソケットを作成する
2. ソケットをネットワークインターフェイスにバインドする
3. 特定のネットワークインターフェイスにバインドされたソケットをリッスンする
4. 着信接続を受け入れる
5. ソケットのイベントに応答する

5番目を除くすべてのポイントは比較的類似しており、ほとんど関心がありませんが、ソケットで発生するイベントに応答するための多くのメカニズムがあり、それらのほとんどは各プラットフォームに固有です。



Windowsを見ると、次の方法がわかります。

1. 選択を使用します。 基本的に、他のプラットフォームのコードとの互換性のために、ここではそれ以上の利点はありません。
2. WSAAsyncSelect-ウィンドウ化されたアプリケーションがソケット上のイベントをウィンドウ化されたキューに送信するように設計されています。 速くはなく、サーバーコードメカニズムとしては興味深いものではありません。
3. WSAEventSelectは、ネットワークインターフェイス上のイベントオブジェクトを処理します。 すでにより魅力的なツール。 つまり 同時にサービスを提供する接続が数百を超えないようにサーバーを計画する場合、これはパフォーマンス/開発速度の基準によると最適なメカニズムです。
4. I / Oの重複はWSAEventSelectよりも高速なメカニズムですが、開発するのも面倒です。
5. I / O完了ポート-高負荷サーバーアプリケーション用。

Windows用のネットワークソフトウェアの開発に関する優れた書籍があります-「Microsoft Windowsネットワークでのプログラミング」。



* nixシステムを見ると、イベントセレクターの小さなセットもあります。

1. 同じ選択。 そして再び、彼の役割は他のプラットフォームとの互換性です。 また、監視しているソケットのいずれかでイベントが発生するとトリガーされる（制御を返す）ため、高速ではありません。 このような操作の後、すべてを実行して、イベントが発生したソケットを確認する必要があります。 要約：1つの操作は、観測されたソケットのプール全体で実行されます。
2. pollはより高速なメカニズムですが、監視用の多数のソケット用に設計されていません。
3. epoll（Linuxシステム）とkqueue（FreeBSD）はほぼ同じメカニズムですが、一部のフォーラムの猛烈なFreeBSDファンはkqueueの方がはるかに強力だと強く主張しています。 私たちは聖戦を助長しません...これらのメカニズムは、* nixシステムで負荷の高いサーバーアプリケーションを作成する際の主なものと考えることができます。 動作原理とその尊厳を簡単に説明すると、何かが発生したソケットのみに関連する一定量の情報が返され、すべてを実行して何がどこで発生したかを確認する必要はありません。 また、これらのメカニズムは、同時にサービスされる多数の接続用に設計されています。

記述子のイベントを待機する機能に加えて、さらに小さいが非常に便利なものがいくつかあります。

1. sendfile（Linux）およびTransmitFile（Windows）を使用すると、「送信元」および「送信先」のいくつかの記述子をフィードしてデータを送信できます。 HTTPサーバーでは、ファイルを転送する必要がある場合に非常に便利です。これは、パフォーマンスにプラスの影響を与える、バッファーの割り当てと読み取り/書き込み関数の呼び出しが不要になるためです。
2. aio-特定の量の作業をオペレーティングシステムに転送できます。これにより、ファイル記述子で非同期操作を実行できるようになります。 たとえば、システムにバッファーを伝え、シグナルをどのように終了するかをこのファイル記述子に書き込みます（読み取りと同様）。
3. Neiglアルゴリズムは、バッファリングの遅延なしにネットワークにデータを少しずつ送信する必要があるアプリケーションを作成するときに役立ちますが、常に役立つとは限りません。 HTTPサーバーなどのアプリケーションでは、システムに送信データをバッファーし、可能な限り有用な情報とともにTCPフレームに送信するように指示することをお勧めします（これには、TCP_CORKなどのソケットオプションを使用できます）。
4. そしてもちろん、ノンブロッキングソケット。 コメントなし...
5. また、writev（nix）などの関数（およびWindowsの同様のWSA関数）を使用すると、複数のバッファーを一度に送信できます。これは、HTTPパケットヘッダーとそれに添付されたデータを送信し、同時にシステムコールの数を節約する必要がある場合に便利です。

ライブラリーをスターター用のコードとともに使用することをお勧めします。これについては、例としてboost.asioとlibeventを使用して行います。 boost.asioはネットワークアプリケーションの開発を大幅に簡素化します。libeventはサーバークラシックです。

Epollの実装

epoll、poll、selectのネットワークイベントに応答するためにどのようなメカニズムを選択したとしても、他にも多くのニュアンスがあります。



マルチスレッドサーバーを実装する際の最初の質問の1つは、スレッド数の選択です。 かつてトレーニングや疑似戦闘の目的で「ソケットサーバー」をすばやく組み立てる必要があった人のほとんどは、「1つの接続-1つのスレッド」という戦略を選択しました。 このアプローチには長所と短所があります。 最大のプラスは、開発の容易さです。 多くの欠点があります：大量のシステムリソース、多くの同期アクション（コード、何かと同期する何か）。 ただし、セッション間に特別な共通部分がないため、このアプローチは同期の点でHTTPサーバーにとって悪いことではありません。 しかし、開発の単純さにもかかわらず、私はその実装のためにこの戦略を考慮しませんでした。 スレッド数の最適な選択にはさまざまな推奨事項があります。これは、システム内のプロセッサ/プロセッサコアの数で、同じ数ですが、特定の係数があります。 提案された実装では、ワーカースレッドの数は、サーバーの起動時にユーザーによって設定されるオプションのパラメーターです。 私にとっては、ワークフローの数はプロセッサ/コアの数に2を掛けたものに等しいと判断されました。

現在のコンテキストでは、ワークフローはユーザー要求を処理するスレッドとして理解される必要があります。 これらのフローに加えて、リスニングストリームとメインストリームの2つが含まれていました。 リスニングストリーム-サーバーソケットをリッスンし、着信接続を受け入れ、処理のためのワークフローのキューに入れられます。 メインスレッド-サーバーを起動し、ユーザーからの特定のアクションを待って停止します。



この例を実装するときに興味を持った2番目の質問は、epollを使用する際のフローとネットワークイベントの処理方法です。 私が最初に思いついたのは、1つのスレッドでepollによって監視されているすべてのイベントに反応し、それらを他のスレッド（ワーカー）で処理し、特定のキューに渡すことでした。 つまり 1つのスレッドは、リスニングソケット上の着信イベントと、受信した接続へのデータの到着に関するイベントと、閉じられている接続に関するイベントの両方を監視します。 イベントを取得し、キューに入れ、ワーカースレッドに通知し、新しい接続を受け入れるためにacceptと呼ばれるワーカースレッドを追加し、epoll、読み取り、書き込みを追加し、接続の監視ソケットのプールを閉じます。 ソケットからのデータの読み取りなど、1つのイベントの処理中に、ソケットを閉じることに関するイベントがこのソケットのキューに既にある可能性があるため、決定は間違っています。 もちろん、読み取りはエラーで失敗しますが、接続に関連するすべてのリソースをクリアする手順にはなりませんが、キューからこのイベントを減算する場合のみです。 私の実装では、多くのソケットクロージャイベントが失われました。 実装はより複雑になり、同期の場所の数が増え、奇妙な状況ではドロップが発生しました。 滝は別の理由でした。 epollイベントの構造内の各ソケットでは、ユーザーデータとして、ポインターがセッションオブジェクトにアタッチされ、クライアントオブジェクトが閉じられるまで、クライアントとのすべての作業を行いました。 イベント処理のシーケンスがより複雑になったため、ユーザーデータとして関連付けられたオブジェクトが既に削除されたため（たとえば、セッションが外部イベントによってではなく、内部のセッション自体のロジックによって閉じられたとき）、これにより、既に壊れたポインターでの処理。 最初のアイデアから「熊手で」そのような経験を受け取ったので、別の戦略が採用されました：epollによるメインリスニングストリームは、リスニングソケットのイベントにのみ応答し、着信接続を受け入れ、その数が待機キューに許可されている場合、それらを閉じますそれ以外の場合、受信した接続を処理のためにキューに入れます。 ワークフローはこのキューを差し引いて、このソケットをepollセットに入れます。 ワークフローはepoll記述子で動作し、すべてが1つのストリームのフレームワーク内で行われます：epollへの配置、データ到着のイベントへの反応、読み取り/書き込み、終了（ハンドルが閉じられると、epollからの削除はシステムレベルで自動的に行われます） 。 このような組織の結果として、着信接続のキューを保護する同期プリミティブは1つだけです。 一方では、リスニングストリームのみがこのキューに書き込み、他方では、受信された接続のために受信されたフローが選択されます。 1つ少ない問題。 epoll構造のユーザーデータを使用したセッションオブジェクトへのポインターのバインドを放棄します。 解決策：連想配列を使用します。 キーはソケット記述子であり、データはセッションオブジェクトです。 これにより、イベントが発生したとき、epollイベントからユーザーデータを取得する機会があるときだけでなく、何らかのロジックに従って、たとえばタイムアウトによって接続を閉じる必要があるとき（接続プールが利用可能）にセッションを操作できます。



最初のオプションは、完全に1つのファイルに記述され、C＃/ Java開発者のスタイルで（宣言と定義に分割することなく）、1800行以上のコードがありました。 テストタスクには多すぎます。HTTPプロトコルの実装が最小限であるという事実にもかかわらず、他の何もせずにHTTPヘッダーのパラメーターを最小限で処理してGET / HEADを処理するための最小限です。 それはポイントではありません。 繰り返しになりますが、テストタスクは単に何かを試す「キック」でした。 このソリューションでの私の主な関心は、HTTPプロトコルの実装ではなく、マルチスレッドサーバーの実装、接続とセッションの管理でした（セッションは、接続に関連する処理アルゴリズムを持つ論理データ構造として理解できます）。

この巨大なファイルを破壊し、いくつかの場所で実装をとかすと、次のようになります。

class TCPServer : private Common::NonCopyable { public: TCPServer(InetAddress const &locAddr, int backlog, int maxThreadsCount, int maxConnectionsCount, UserSessionCreator sessionCreator); private: typedef std::tr1::shared_ptr<Common::IDisposable> IDisposablePtr; typedef std::vector<IDisposablePtr> IDisposablePool; Private::ClientItemQueuePtr AcceptedItems; IDisposablePool Threads; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはおそらく、私が記述しなければならなかった最短のサーバークラス実装です。 このクラスは、リスナーと複数のワーカーの複数のスレッドのみを作成し、それらのホルダーです。 また素晴らしいではありません。 両方のクラスは だから イベントフロークラスを使用する 。 このスレッドは 承認された化合物の記述子で発生するイベントに対する反応を整理するため。

サーバーのソースクラスを見ると、ユーザーセッションクラスを作成するためのファンクターが最後のパラメーターとして渡されていることがわかります。 ユーザーセッションはインターフェースの実装です

 struct IUserSession { virtual ~IUserSession() {} virtual void Init(IConnectionCtrl *ctrl) = 0; virtual void Done() = 0; virtual unsigned GetMaxBufSizeForRead() const = 0; virtual bool IsExpiredSession(std::time_t lastActionTime) const = 0; virtual void OnRecvData(void const *buf, unsigned bytes) = 0; virtual void OnIdle() = 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このインターフェイスの実装に応じて、異なるプロトコルを実装できます。 InitメソッドとDoneメソッドは、それぞれセッションの開始時と終了時に呼び出されます。 GetMaxBufSizeForReadは、データ読み取り操作中に割り当てられる最大バッファーサイズを返す必要があります。 読み取られたデータはOnRecvDataに含まれます。 セッションが期限切れになったことを伝えるには、IsExpiredSessionを適切な方法で実装する必要があります。 OnIdleはいくつかのアクションの間に呼び出されます。ここで、セッション実装はいくつかのバックグラウンドアクションを実行し、インターフェイスを介して閉じることを目的として自身をマークできます。

 struct IConnectionCtrl { virtual ~IConnectionCtrl() { } virtual void MarkMeForClose() = 0; virtual void UpdateSessionTime() = 0; virtual bool SendData(void const *buf, unsigned *bytes) = 0; virtual bool SendFile(int fileHandle, unsigned offset, unsigned *bytes) = 0; virtual InetAddress const& GetAddress() const = 0; virtual SocketTuner GetSocketTuner() const = 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IConnectionCtrlインターフェイスは、ユーザーセッションがネットワークにデータを送信できるように（SendDataおよびSendFileメソッド）、閉じられるように自身をマークできるように（MarkMeForCloseメソッド）、「生きている」（UpdateSessionTimeメソッド。 IsExpiredSession）、同じセッションは着信接続（GetAddressメソッド）のアドレスとソケット設定のSocketTunerオブジェクト（現在の接続（GetSocketTunerメソッド））を取得できます。

HTTPプロトコルの実装は、HttpUserSessionクラスにあります。 上で言ったように、HTTPの実装は私にとって最も興味深くも優先度も低いので、あまり考えませんでした。 私は何が起こったのかを書くのに十分であると正確に思った:)

Libeventの実装

libeventでの実装は今でも私にとってお気に入りです。 このライブラリにより、非同期入出力を整理し、ネットワークプログラミングの微妙な点の多くを開発者から隠すことができます。 これにより、データやその他のイベントの受信、送信、データの非同期送信のためのコールバック関数をハングアップすることにより、生データの処理を実装できます。 データの低レベルの作業に加えて、高レベルのプロトコルもあります。 libeventにはHTTPサーバーが組み込まれているため、要求ヘッダーの解析と同じ応答ヘッダーの生成を抽象化できます。 ライブラリおよびその他の機能を使用してRPCを実装することができます。

組み込みを使用してHTTPサーバーを実装する場合、シーケンスは次のようになります。

1. event_base_newを呼び出して、いくつかの基本的なオブジェクトを作成します（より簡単な場合のために単純化されたevent_initもあります）。 オブジェクトを削除するペアの関数はevent_base_freeです。
2. evhttp_newを呼び出して、HTTPエンジンオブジェクトを作成します。 evhttp_freeオブジェクトを削除するためのペア関数。
3. フラグの組み合わせでevhttp_set_allowed_methods関数を使用して、サーバーがサポートするメソッドを指定できます。 したがって、たとえば、GETメソッドのみをサポートするには、evhttp_set_allowed_methods（Http、EVHTTP_REQ_GET）のようになります。ここで、Httpはステップ（2）で作成された記述子です。
4. evhttp_set_gencbを呼び出して、着信要求を処理するコールバック関数を設定します。
5. evhttp_accept_socket関数を呼び出して、リスニングソケットをHTTPサーバーオブジェクトのインスタンスに関連付けます。 リスニングソケットは、同じソケット/バインド/リスンを介して作成および構成できます。
6. event_base_loop関数を呼び出して、イベントループを開始します。 event_base_dispatchという簡単なオプションがあります。 event_base_loopはループで呼び出す必要があります。 この関数は、インストールされたコールバック関数への呼び出しが行われるライブラリの腸内で何か有用なことを行うか、何もする必要がない場合に制御を返し、この時点で何か便利なことができます。 また、メッセージ処理サイクルの寿命をより簡単に制御することも可能になります。
7. リクエストハンドラでは、evbuffer_add_printfを呼び出してテキストデータを送信するか、ライブラリにファイル記述子を指定して、evbuffer_add_fileを呼び出して送信することができます。 これらの関数は、自分で作成する（時間内に削除することを忘れないでください）か、要求フィールドevhttp_request :: output_bufferを使用できるバッファーオブジェクトで動作します。 すべての魅力は、これらの関数が非同期であるということです。 ファイルを送信する例では、ファイル記述子を同じevbuffer_add_fileに渡すと、すぐに制御が返され、ファイルが送信された後、ファイル自体が閉じられます。

すべてが1つのスレッドで非常に美しくなりますが、判明したように、マルチスレッドサーバーを作成することも難しくありません。 boost ::スレッド、またはストリームの作業をカプセル化するクロスプラットフォームクラスなどを使用すると、libeventはクロスプラットフォームライブラリであるため、完全にクロスプラットフォームのソリューションを取得できます。 私自身の実装では、Linuxのストリームに対してのみラッパーを使用します。 しかし、これはそれほど重要ではありません。

各ワークフローのメインスレッドは、独自の記述子を作成する必要があります。 手順1〜5を完了します。 ワークフローは、メッセージ処理サイクルのみをねじる必要があります-ステップ6。各ワークフローでステップ7が実行されます。 要約すると、1つのリスニングソケットを作成し、その処理を複数のワーカースレッドに課します。

そのため、実装では、ストリーム、ファイル、およびコマンドライン解析用のプリミティブが既にいくつかあるため、C＃/ Javaスタイルで約200行のGETメソッドのみをサポートするHTTPサーバーを取得しました。 起こっていることを完全に制御してコードを記述する作業のこの削減は、喜ばしいことです。 さらに、主観的に、結果のサーバーは少し速く動作しますが、最後にテストを見てみましょう...

boost.asioでの実装

boost.asioはboostの一部であり、ネットワークアプリケーション、およびクロスプラットフォームアプリケーションの開発を大幅に削減するのに役立ちます。 ライブラリは、開発者から多くのルーチンを隠します。

ブーストでHTTPサーバーの実装を作成しませんでした。 完成した例をboost.asioに取りました。 マルチスレッドHTTPサーバーの例。 HTTPサーバー3この例の実装は、上記の例と組み合わせたテストに非常に適しています。

テスト用のHTTPサーバーの実装がありますが、一般的な原則について話すのは悪くありません...残念ながら、libeventとは異なり、boost.asioはHTTPなどに類似した高レベルのプロトコルをサポートしていません。 この場合、ライブラリはTCPを介したネットワークでの作業を隠しますが、プロトコルヘッダーを収集および解析するには、HTTPの実装を開発者自身が行う必要があります。

以下は、このトピックに照らしてHTTPヘッダーを解析/収集するのはあまり面白くないので、説明付きのマルチスレッドエコーサーバーの小さな例です。 boost.asioを使用してマルチスレッドサーバーを作成する手順は次のとおりです。

1. boost :: asio :: io_serviceおよびboost :: asio :: ip :: tcp ::アクセプタークラスのオブジェクトを作成します。
2. boost :: asio :: ip :: tcp :: resolverおよびboost :: asio :: ip :: tcp ::エンドポイントを使用すると、リスニングソケットがバインドされるローカルアドレスがライブラリで使用される構造に変換されます。
3. bindを呼び出して、クラスboost :: asio :: ip :: tcp :: acceptorのオブジェクトでリッスンします。
4. クラス「接続」を作成します。 別名「セッション」。着信ユーザー接続を受信するときにそのインスタンスが使用されます。
5. 適切なコールバック関数を構成して、着信接続を受信し、データを受信します。
6. boost :: asio :: io_service :: runを呼び出して、メッセージ処理ループを開始します。

また、libeventの例と同様に、マルチスレッドサーバーは、上記の一連の手順を使用してシングルスレッドサーバーから非常に簡単に作成できます。 この場合、シングルスレッドサーバーとマルチスレッドサーバーの違いは、マルチスレッド実装の各スレッドでboost :: asio :: io_service :: runメソッドを呼び出す必要があることだけです。

テスト中

受け取った工芸品を比較する時が来ました...

すべてが開発およびテストされたプラットフォームは、4GBのRAMとUbuntu 12.04デスクトップを実行する2コアプロセッサを搭載した通常のラップトップです。

まず、テスト用のユーティリティを配置します。

 sudo apt-get install apache2-utils
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法でテストします：

 ab -c 100 -k -r -t 5 "http://127.0.0.1:5555/test.jpg"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのサーバーについて、4つのワークフロー、100の並列接続、2496629バイトの送信用ファイル、および5秒の推定時間間隔が設定されました。

結果：







結果は表にまとめられています。

	エポール	libevent	boost.asio
完全なリクエスト	2150	1653	639
転送された合計（バイト）	5389312814	4263404830	1655047414
転送されたHTML（バイト）	5388981758	4263207306	1654999464
1秒あたりのリクエスト[秒]（平均）	428.54	330.05	127.78
リクエストあたりの時間[ms]（平均）	233.348	302.987	782.584
受信した転送速度[キロバイト/秒]	1049037.42	831304.15	323205.36

嘘には、嘘、露骨な嘘、統計の3種類があります。 認めざるを得ないが、結果は私を喜ばせざるを得ない。 結果に特別な注意を払うべきではないと思いますが、サーバーソフトウェア用の開発ツールの選択を決定する際に役立つかもしれないサポート情報としてそれらを見ることができます。 結果を正確にするために、サーバーハードウェア上で複数の実行、ネットワーク上の他のマシンで実行中のクライアントなどを配置することをお勧めします。

100並列クエリ-これは小さいように見えますが、そのような控えめな条件でテストするには十分です。 もちろん、何千もの並列クエリの結果を確認したいのですが、すでに他の要因があります。 そのような要因の1つは、プロセスで同時に開くことができるファイル記述子の数です。 getrlimitおよびsetrlimit関数を呼び出すことにより、いくつかのプロセスパラメータを見つけて設定できます。 プロセスごとに割り当てられているファイル記述子の数を調べるには、rlimit構造体のフラグRLIMIT_NOFILEを指定してgetrlimitを呼び出すことができます。 オペレーティングシステムの場合、これらはデフォルトでプロセスごとに1024個のファイル記述子であり、プロセスに設定できる最大4096個です。 … , , . Linux

WebServer «» , , . . , - , - , - - . , epoll . , , . « », , , C++, C, stl, .

, libevent, , , , . .

, boost . . boost.asio . «» , , .

Linux (aio) , «» .



SVN . , . しかし！ , . « » , , — , — , — . :)



«» API .

• HTTP libevent
• Boost network performance with libevent and libev
• MULTI-THREADED HTTPSERVER USING EVHTTP (LIBEVENT)
• Boost application performance using asynchronous I/O
• FreeBSD 100-200

ご清聴ありがとうございました！