nxweb-Cアプリケーション用のHTTPサーバー

nxwebは、Cアプリケーション用の新しい組み込み高性能Webサーバーです。 機能面では、これはHTTPリクエストハンドラを記述するためのフレームワークです。 類似物：G-WAN / libevent / Mongoose、Apache / mod_ <好きな言語>、Tomcat、Node.js。 開発者-Yaroslav Stavnichy。 私は主にこのプロジェクトに興味がありました。それは既存のソリューションに代わる真の選択肢であり、それぞれに欠点があるためです。 選択は良いです。 また、このサーバーの機能、長所と短所の組み合わせが好きかもしれません。



カットの下で、開発者とのインタビューからのプロジェクトに関する詳細情報。



Q：自分について教えてください、あなたは何をしていますか、どこで働いていますか？



Yaroslav：私は長い間ソフトウェアを開発しています。 Nexoft Company。 私は主にJavaで書いていますが、高速で何かをする必要があるときにC / C ++を思い出すこともあります。 たとえば、トラフィックの多いサイト用のバナーツイスターエンジン。



Q：それでは、nxwebはバナーをねじるという目的で作成されましたか？



Yaroslav：バナーだけでなく、これは最初のタスクの1つです。 少なくとも、特定のタスクは抽象的ではありません。



Q：高トラフィックとは、1秒あたりのリクエスト数です。



Yaroslav：現在、1秒あたり約100件のリクエストが来ています。 それらの一部はTomcatに送信されます。 ただし、各HTMLページには最大20個のバナーコードが挿入されます。 サーバーは原則として難しいので、短いHTMLフラグメントを返すという単純なタスクで彼に負担をかけたくないだけです。 もちろん、真珠でもうまくいくかもしれませんが、簡単な方法を探しているわけではありません。



実際、私は長い間このようなエンジンを持っていて、それはApacheのモジュールとして書かれていましたが、最近、すべてのプロジェクトをnginxに移行しています。



一般に、Apacheとnginxのモジュールを書くのは楽しい経験ではありません。 移植性への懸念から課される見掛け倒しがたくさんあります。 さらに、それらはマルチプロセスであり、これは別の問題です。 スレッドを使用すると、物事がずっと簡単になります。 共有メモリは貴重です。 私はJavaに慣れています。 私はnginxの中に登りましたが、すべてが非常に面倒で、さらに共有メモリなどもあります



Mongooseのようなマイクロエンジンにアプリケーションを実装しようと決めたのですが、先ほどネットワークで見つけました。 彼は掘り始め、さらにいくつかの選択肢を見つけました。 G-WAN。 クローズドソースを除いて、私はそれに関するすべてがとても気に入りました。 G-WANは静的な荷送人としてではなく、アプリケーションサーバーとして正確に試しました。 しかし、すぐにグリッチに遭遇し始めました。グリッチは、閉じられたコードのために見つけて修正することができませんでした。



だから、私はMongooseにひねりを書いて、パフォーマンスをテストし始め、G-WANと比較してすでに非常に低いことがわかりました。 2500スレッドを実行することを推測したのは後になってからでしたが、最初は8〜16で十分だと思いました。 非常に多くの場合、何もありません。



Q：mongooseはリクエストごとに1つのOSスレッドを使用するためですか？



Yaroslav：はい。実際、2500スレッドも解決策ではありません。 彼らは大量のメモリを消費し、再び、2501番目のリクエストが表示されます-そしてこんにちは...



彼はさらに深く掘り始め、microhttpdとlibeventを見つけました。 パフォーマンスの点では、G-WANと比較すると、見た目が青白く見えました。 このすべてを扱ってソースを詳しく調べていたときに、Webサーバーの作成はそれほど難しくないことに気付きました。 たとえば、mongooseでは、HTTP応答全体をモジュール開発者に手動で書き込む必要があります。



libeventは最も有望であるが、シングルスレッドに見えました。 libev（libeventの軽量の代替）に対しても同じことをやり直すことにしました。 それでnxwebが生まれました。 主な最初の目標は、フル機能のサーバーではなく、C Webアプリケーションです。 すでにCで何かを開発している場合は、それを非常に高速に動作させたいのです。つまり、プラットフォームも高速でなければなりません。 そして、あなたはマングースの下で書きます、そして、彼が試みたもののために、彼がブレーキですべてをリリースするかどうか疑問に思うでしょう。



誰とも競争するつもりはありませんでした。 速度の標準に関しては、G-WANに近づきたかったのです。 しかし、プロジェクトが公開されるとすぐに、すぐに手紙が流れました。 彼らは皆私を見つめ始めました。 そのため、G-WANを追い抜くには、さらに数日を費やさなければなりませんでした。



私は彼を追い抜いたかどうか、まだ明確ではありません。 私のコンピューターでは、彼を追い越しました。 彼らが言うように、その領域で。 繰り返しますが、おそらくすべてのモードではありません。



ちなみに、nginxは非常に喜んでいました。 HTTPスタックの速度は、G-WANの速度よりも高速です（正しく構成されている場合はもちろん）。 リクエストされていない場合、nginxはメモリ内のファイルをキャッシュしません。 一般的にnginxと競合する意味はありません。 このような機能的なサーバーがどのように高速を提供するかは驚くべきことです。 ここで、strcatの代わりにsprintfを基本的に使用すると、1秒あたり5〜1万リクエストでパフォーマンスを発揮できると確信しました。 つまり 余分なCPU命令ごとにすでに戦いは終わっています。



Q：それでは、nxwebアーキテクチャについて簡単に説明してください。



Yaroslav：メインスレッドはソケットをリッスンし、着信接続をネットワークフローにプッシュします（各スレッドはミューテックスを避けるために独自の順番を持っています）。 ネットワークストリーム（プロセッサコアで一度に1つずつ実行するのが理にかなっています）は、HTTPプロトコルを提供します。 リクエストをデコードし、ハンドラーモジュールに渡します。 ワーカーはオプションであり、ネットワークフローを停止しないように、低速ハンドラーのみをサポートするように設計されています。



これで、モジュールにはコールバックがあり、メインループに入る前にサーバーによって呼び出されます。 削除または置換できるmain.cファイルもあります。 その機能はサービスのみです。ログファイルを開き、_nxweb_main（）に制御を転送します。 彼はまた、悪魔を発射する方法を知っています。 ダブル：1つの悪魔が、2番目の（nxwebが実際にスピンする）が停止しないことを保証します。 内部デーモンがクラッシュした場合、最初のデーモンが自動的に再起動します。 必要に応じて、main.cを他のものに置き換えることができます。 最も重要なことは、_nxweb_main（）を呼び出すことです。



Q：各ネットワークストリームがループを受け入れないのはなぜですか？ その後、OSは接続を分散できるようになり、異なるカーネルで複数の受け入れを並行して行うことができます。



Yaroslav：両方のオプションを試しました。 メインの参加なしでネットワークフローを受け入れます。 速度の違いは見当たりませんでしたが、単一のアクセプターに戻りました。これにより、接続エラーの割合が減少するように思えました。 nginxとG-WANを使用すると、接続の一部がフリーズし、負荷がかかりません。 ベンチマークページで実際の同時実行性に関するコメントを参照してください。



Q：なるほど。 最初のバージョンではlibevを使用していましたが、今ではwikiはlibevに依存しないと述べています。 何が変わった？



ヤロスラヴ：私はリベフを書きました。 これがまさに「G-WANを追い越すために息を吹きかける」という意味です。 私のニーズのために投獄されており、独立したプロジェクトではありません。 言い換えれば、私は現在epollを直接操作しています。 nxwebは完全に移植性がありません。 Linuxでのみ動作し、カーネル> = 2.6.22でも動作します。 Edge-Triggered epollを使用していますが、libevはその不耐性のためサポートしていません。 はい、libevは非常にクールなものです。私はそれをやめますが、人々はそれをより速く望んでいました。 それは苦しむ必要がありました。



Q：エッジトリガーは最後のゲインでしたか？



ヤロスラフ：それだけではありません。 また、コードを作成する必要がありました。 特に、sprintf、新しいメモリバックアップシステムなどを除外します。 これらすべてをlibevに戻すという考えがあります。 悪くはないかもしれませんが、行くかどうかはわかりません。 移植可能なコードを作成する必要はありません。 ホスティングはほとんどの場合Linux上で行われます。 また、libevは、nxwebをビルドするためにインストールする必要がある追加の依存関係です。 マイナスも。



Q：Igor Sysoevとlibevの著者は、epollには多くの問題があると主張しています。 まだ出会ったことがありますか？



Yaroslav：現代のコアのこれらの問題がすでにクリーンアップされていることを期待しています。 それでも、何年も経ちました。 2.6.32および3.0.0でテストしていますが、問題は発生していません。



Q：メモリのバックアップはどうですか？ シスコルを少なくするために、ある種の大きなプールを割り当てていますか？



Yaroslav：接続用のフリーリストと、応答を生成するための独自のobstack対応物。



Q：HTTPパーサーの独自の実装を使用していますか、または何か準備ができていますか？



Yaroslav：独自の実装。 もちろん、HTTPプロトコルのすべてのニュアンスを完全にサポートしているわけではありません。 たとえば、私は100-continueまたはchunked-encodingを持っています。 繰り返しますが、輸送統計はモジュールの仕事です。 カーネルは要求を解析し、ハンドラーを呼び出し、応答を受信し、HTTPでラップして、クライアントに送信します。 つまり ETagとRangeはすべてそこにあります-これはモジュールのタスクです。 現在、sendfile.cモジュールはメインヘッダーのみを生成しますが、おそらくRangeとIf-Modified-Sinceをすぐにサポートするでしょう。



はい、おそらくエラーをチェックする既製のパーサーがあります。 しかし、一方で、私自身のパーサーでは、他の誰かよりも、彼らがそれについて私に言った場合、私はより迅速にエラーをキャッチします。 ここでは、実際に費用はCPU命令に費やされます。 また、パーサーのすべての独立したプロジェクトは非常に包括的であるため、パーサーのパフォーマンスに疑問の余地はありません。



Q：一方、nginx以外には戦闘サーバーの外部ポートをリッスンさせません。 そしてその後、すべての不正なリクエストはすでにフィルタリングされています。



Yaroslav：現時点（バージョン2.0）では、nxwebは公開する準備ができていません。 ほとんどの場合、実際のアプリケーションはCスクリプトで構成されているだけではありません。 Javaとstaticの両方とその他すべてを結び付ける必要があります。 チャットの実装に関しては、何千もの同時接続を維持することが重要です。



Q：Cにはユーザーランドスレッドを作成するライブラリがいくつかありますが、そのうちの1つはmongrel2で使用されるlibtaskです。 各コルーチンには独自のスタックがあるため、ライブラリにはスタックを切り替えるための複数のアセンブラー命令が含まれています。 これにより、on_request、on_successなどのコールバックなしで通常のシリアルコードを記述できます。



Yaroslav：はい、コルーチンについて聞いたことがあります。 ただし、コールバックですべてをすでに記述している場合、コルーチンに切り替えてもパフォーマンスは向上しません。 余分なメモリのみがスタックのストレージに入ります。 はい、そしてgdbの問題-また、最も快適ではありません。 それは好みと習慣の問題です。 コルーチンに慣れる必要があります。 これは特別な概念です。



Q：リクエスト/レスポンスだけでなく、たとえば、途中でスリープしたり、データベースにアクセスしたいときに、ハンドラーのコードをサポートすることで大きなメリットが得られます。 もちろん、単純なバナーのひねりのために、それらには意味がありません。



Yaroslav：スリップインと基地に行くために-それが私が労働者に提供したものです。 そして最初のものをチェックしました。 100人のワーカーが構成され、各ワーカーが1秒間スリープすると、サーバーは1秒あたり100リクエストをスムーズに、ためらうことなく処理します。 G-WANもnginxもこれを処理できません。 彼らは毎秒3-4のリクエストを発行するか、愚かにハングします。



ただし、緊急にベースにアクセスする必要がある場合は、この目的のために非ブロッキングアダプタを作成できます。 サーブレットからの呼び出しが1つあります-データベース要求をキューに入れ、コールバックを登録します。 この復帰後、コールバックは引き続き機能します。 原則として、ここでは、執筆の便宜上、コルーチンについて考えることができます。



Q：nxwebの現在のステータスをどのように説明しますか？ 安定性、間違い？



ヤロスラヴ：さて、私はすでにかなりのトラフィックのあるサイトのバックエンドとしてそれを台無しにしました。 生産開始。 1回の再起動/失敗ではなく、1か月が経過しました。 バックエンドは火の最も厳しい洗礼ではありませんが。



ステータスはアルファだと思います。 特に、nxwebのすべての機能が完全にテストされているわけではありません。 たとえば、チャンク化された要求エンコード。 テストケースでは機能しますが、何がポップアップするかはわかりません。 また、クライアントの動作が正しくない場合の安定性も不明です。 たとえば、エラーのあるリクエストは失敗の原因になります。



現在の段階ではまだ問題があります。h-ファイル、データ構造などを積極的に変更しています。



Q：個人的に、nxwebの潜在的な開発者として、すべてのリクエストの処理と、URLの比較、sendfile、ヘッダーの挿入、Cookieの解析、バックエンドへの転送などの補助機能の厚いライブラリ（これはモジュールの形式で適切です）を完全に制御する機能が必要です。 これは、nxwebでクリティカルセクションをプログラミングすることを想像する方法です。



ヤロスラフ：これはほぼ私のアプローチだと言わなければなりません。 サーバーを構成できる基本機能を作成します。 ただし、何らかの構成ファイルの助けを借りずに、Cで構成してください。 なぜなら、nginxが持つ設定の類似物を作成することは非常に難しい作業だからです。



Q：次の質問は、ダニの可能性が高いですが、Windowsサポートについてどう思いますか？



ヤロスラフ：99％除外。 私は通常、コードの移植性を冷静に見ています。 実際、nginxの内部インターフェイス（およびApache）が非常に混乱しているのは、移植性に関する懸念のためです。 コードの移植性のために、最新のテクノロジーを放棄する必要があります。 今のところ、私はLinuxのみに集中したいと思っています。



Q：G-WANには、アプリケーションの自動コンパイルというかなり便利な機能があります。 もちろん、セキュリティ、コンパイラフラグ、その場での更新など、多くの未解決の質問があります。 同じ機能をnxwebに追加する予定はありますか？



Yaroslav：はい、私は彼女が本当に好きでした。 しかし、私はまだ計画していません。 余分なExtra。これは、nxwebを自分のニーズに完全に使い始めることに決して近づきません。



Q：さて、より差し迫った質問は、nxwebをどのような形で配布する予定ですか？ ソースツリー？ 図書館？ 静的/動的？



ヤロスラフ：これまでのところ、私がすでに配布しているものだけです。 ソースをダウンロードしてmakeを実行できるオープンなリポジトリ。 現時点では、プロジェクトの完全なコンパイルには数秒かかります。 図書館に損害を与えるポイントはまだ見当たりません。



Q：Hello Worldアプリケーションを書きたいとしましょう。 私の行動



Yaroslav：hello.cはモジュールテンプレートです。 さらに、Makefileには、モジュールの接続に関する小さなコメントがあります。 特別な変数SRC_MODULESおよびINC_MODULESがあります。 さらに、modules.cでモジュールへのリンクを追加する必要があります。



モジュールを使用するプロセスには、特にモジュールがさらに多い場合は、何らかの方法でより適切に装備する必要があることに同意します。



モジュールの組織的な開発は次のようになります。nxwebをbitbucketでフォークするか、nxwebを別の場所にクローンします。 そこで開発を行い、コミットするなど。 nxwebを更新するには、hg pull ... / nxwebを実行します



Q：何らかのドキュメント、可能なモジュールの説明が必要です。 典型的な問題を解決する例。



Yaroslav：hello.cの例がある限り、そこから多くのことが明らかです。 そして、残りはソースコードのみです。 bitbucketにはwikiがあり、ドキュメントの一部があります。



Q：次に-興味のある開発者に連絡する場所。 ニュースレター/フォーラム。 歴史と検索を含む質問と回答の場所。



Yaroslav： 先日 、2つのGoogleグループnxwebとnxweb-ruを作成しました。



Q：安定バージョンはいつAPIをフリーズしますか？



ヤロスラヴ：ああ、わからない... APIの凍結はもうすぐではない。 ただし、モジュールの変更の第1バージョンと第2バージョンの間は最小限でした。 サーバーの内部がすべてやり直されたという事実にもかかわらず。



Q：これは良い兆候です。 アプリユーティリティライブラリを構築する予定はありますか？ 具体的には、ロギング、テンプレートエンジン、ヘッダーの操作、Cookie。



Yaroslav：ヘッダーとCookieは既にテーブルに解析されており、名前で取得できます。 他に何ができるのか分かりません。 access_log-まだ必要ありませんでした。原則としては複雑ではありませんが、作業が大幅に遅くなります。 補充されたプロキシ関数で始まるユーティリティライブラリ、と思います。



Q：アクセスログは必要ありません。アプリケーションのログが必要です。



Yaroslav：ロギングは一般的です。 いわゆるerror_log、関数nxweb_log_error（ ""、...）。 各行の後にフラッシュされます。



Q：さらに、計画によると。 スレッドの数を自動的に構成することは素晴らしいことです。 ここには2つの方向があります。1）起動時に、コアの数を決定し、非常に多くのスレッドを配置します。2）LAが指定された値を下回っている間に新しいスレッドを生成します。



Yaroslav：自動設定は大きな問題です。 nxwebは、原則として、再コンパイル以外の方法でまだ構成されていません。 1つのパラメーターを自動的に構成可能にすることは理にかなっていますが、わかりません。 実際、起動時に自動的に決定された数のスレッドを簡単に起動できます。 実行可能ですが、プロセス内のスレッドを開始または停止することはもう少し困難です。



実用的な目的のために、私はまだプロキシの実装を見ています。 主にJavaで。 これが私が取り組んでいるものです。 次に-SSL、マネージドキャッシング。 データベースへのインターフェースかもしれません。



これで、リクエストとレスポンスは完全にバッファリングされました。 これは、一部のタスク（たとえば、ファイルのアップロード）に悪い場合があります。 したがって、部分的に受信したデータハンドラーの概念をモジュールに導入し、データを部分的に送信することを考えています。



Q：nginxができるように、プロキシとSSL。 nxwebを外に置かないでください。



Yaroslav：外に出さないと、速度の利点がすべて失われます。 昨日、nginxの背後でnxwebをテストしました：1秒あたり25kリクエスト。 彼は16万を与え、nginxは13万を与えることができるという事実にもかかわらず。 これは、バックエンドのキープアライブを持たないnginx 1.0の現在の安定バージョン用です。 バージョン1.1では、1秒あたり5万件のクエリを取得します。はるかに高速ですが、3倍以上の速度低下があります。



Q：nxwebのユースケースは、ニーズの異なる2つの大きなカテゴリに分けられるようです。

• バナー、トップラインなどのための多くのRP。その後、外に置く必要があります。オプションはありません。
• 要求の負荷は小さいですが、できるだけ早く回答することが非常に重要であるため、アプリケーションの一部はCで記述されています。 ここでは、管理者の利便性のためにnginxに立ち向かうことが非常に適切です。

Yaroslav：nxwebの新しいバージョンでは、新しいユースケースもあると思います。