Nginx +サーバーサイドJavaScript

...またはPHP + JavaScriptからJavaScript + JavaScriptに切り替える方法

サーバーサイドJavaScriptでプロジェクトを実装するというアイデアは、かなり前のことです。 問題は、適切なサーバーソフトウェアの不足でした。 既存のオープンソースプロジェクトは、さまざまな理由で適合しませんでした。 Apache用のアドオンモジュールをインストールするのは良い考えではありません。パフォーマンスとメモリ使用量の最適化が限界に達しているためです。 jslibを使用してFastCGIを構成できますが、「502 Bad Gateway」の可能性を最小限にしたくはありませんでした。ngx_http_js_moduleプロジェクトはまだ初期段階であり、 ngxv8は実際のアプリケーション向けに十分に開発されていません。 そのため、サーバーサイドjavascriptを独自に実装することにしました。 そして、すべての基本機能をすぐにプログラムして、現実に近い条件でテストできるようにしてください。

nginxをメインWebサーバーとして使用し、TraceMonkey（ Mozilla Firefoxの javascriptエンジン、以前のSpiderMonkey）をjavascriptの「エンジン」として使用し、nginxのモジュールを「接着」することにしました。 一見複雑なことはありませんが、特定の機能が必要でした（そして機能しました！）。 ちなみに、ほとんどのアイデアはPHPから借用しています 。

• マルチスレッド状態での作業を修正
• 各場所のスクリプトハンドラーとハンドラー関数を個別に設定するのではなく、URLで指定されたスクリプトを実行する機能
• スクリプトからinclude（）、sleep（）、alert（）を呼び出し、__ FILE__および__LINE__を使用する機能
• 各スクリプトとスクリプト実行時間に割り当てられるメモリを制限する
• 設定で許可されたフォルダーのリストを指定することにより、スクリプトによって開かれたファイルの保護。 PHPのopen_basedirに少し似ています
• JavaScriptでデータ処理を書き込まないように、リクエストデータ（GET、POSTパラメーター、およびもちろんCookie）の自動分析
• アプリケーション/ x-www-form-urlencodedおよびmultipart / form-dataリクエストのサポート
• 基本認証サポート
• データベースの操作（主にMySQLおよびSQLite）
• ファイルシステムの操作：ファイルの読み取りと書き込み、ファイルの存在の確認など。
• eAcceleratorなどのスクリプトバイトコードキャッシング

さらに、いくつかの他の機能（標準化、構成ファイルの作成などのためのツール）が、メインリストには含まれていませんでした-TraceMonkeyの言語機能で実行できます。

言葉から行動へ！ コンパイルと構成の方法、テストと比較の方法...

アセンブリの詳細については詳しく説明しません。そうしないと、テキストのサイズが非常に大きくなります。 Linuxの「ビルド」プログラムの経験があるユーザーは非常に快適に感じるでしょうが、他のすべての人には、 バイナリアセンブリとセルフコンパイルのプロセスをスキップする機能を提供できます。

あなたが必要になります：

• Linux
• コンパイラCおよびC ++、autoconf 2.13
• Nginxソース
• リポジトリからのTraceMonkey
• NSPRライブラリ
• 私たちのモジュール
• MySQLおよびSQLite（オプション）+開発ツール

組み立て順序は次のとおりです。

最新バージョンの最初のNSPR（執筆時点-4.8.2）：

wget ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.8.2/src/nspr-4.8.2.tar.gz<br/>tar -xzf nspr-4.8.2.tar.gz<br/>cd nspr-4.8.2/mozilla/nsprpub<br/>./configure --prefix=/usr/local --with-pthreads<br/>make<br/>sudo make install<br/>
次に、リポジトリからTraceMonkeyを作成します（執筆時点では、リポジトリバージョン1.8.5で、1.7.0のソースコードのみでファイルをダウンロードできます）。

hg clone http://hg.mozilla.org/tracemonkey/<br/>cd tracemonkey/js/src<br/>autoconf2.13<br/>./configure --prefix=/usr/local --with-nspr-prefix=/usr/local --with-system-nspr --with-pthreads --enable-threadsafe<br/>make<br/>sudo make install<br/>
このステップには、いくつかの理由で問題があります。 まず、誰もがhgコマンドを持っているわけではありません。 次に、すべてのMozilla Firefoxソースがリポジトリからダウンロードされます。 したがって、コードの最初の行を置き換えて、ソースのみTraceMonkeyをダウンロードできます。

# hg clone http://hg.mozilla.org/tracemonkey/<br/>wget http://js.nnov.ru/files/tracemonkey-20100119.tar.gz<br/>tar -xzf tracemonkey-20100119.tar.gz<br/>
そして、すでにコンパイルしています。

次に、nginx（0.8.32）とjavascriptモジュールがあります。

wget http://sysoev.ru/nginx/nginx-0.8.32.tar.gz<br/>tar -xzf nginx-0.8.32.tar.gz<br/>cd nginx-0.8.32/src/http/modules<br/>svn co http://nginx-javascript.googlecode.com/svn/trunk/ javascript<br/>cd ../../..<br/>./configure --prefix=/usr/local/nginx-javascript --add-module=src/http/modules/javascript<br/>make<br/>sudo make install<br/>
すべてがうまくいった場合は、セットアップに進みます。 バイナリアセンブリの幸せな所有者は、構成が既に完了していることを発見しますが、もう一度チェックしても問題はありません。 次の手順に従うだけで十分です。

• javascriptとして処理されるファイルのmime.typesにapplication / x-javascript-serversideタイプを追加します。
  # /usr/local/nginx-javascript/conf/mime.types<br/>types {<br/> ...<br/> application/x-javascript-serverside jsx;<br/> ...<br/>}<br/>
  サーバーが通常のJavaスクリプトをサーバーとして扱わないように、標準の.jsではなく.jsx拡張子が選択されます
• nginx.confファイルの場所/セクションでJavaScript処理を許可します。 同時に、サーバーが動作するポート番号を変更します。
  # /usr/local/nginx-javascript/conf/nginx.conf<br/>...<br/> server {<br/> listen 8081;<br/> ...<br/> location / {<br/> ...<br/> javascript on;<br/> ...<br/> }<br/> }<br/>...<br/>
• nginxを実行します。
  /usr/local/nginx-javascript/sbin/nginx<br/>
• テストhello.jsxスクリプトを作成します。
  // /usr/local/nginx-javascript/html/hello.jsx<br/>print("Hello, people!");<br/>
• hello.jsxがブラウザーで表示されるはずであることを確認します。
  curl http://localhost:8081/hello.jsx<br/>

javascriptサーバーが機能するようになったので、このソリューションは標準のApache + PHPよりもはるかに収益性が高いと思いました。 TraceMonkeyとPHPの内部最適化の問題の心配は少なかったので（たとえば、どのインタープリターが100万ステップのサイクルを高速に実行しますか？違いは小さいと思われます）、スクリプト "Hello、people！"が最初にテストされました。

関係する比較：

• Apache / 2.2.14（プリフォーク）+ PHP / 5.2.12（モジュール）
• nginx / 0.8.32（1ワークフロー）+ javascript
• nginx / 0.8.32（8ワークフロー）+ javascript

テスト環境は、2GBのRAMとDebian Etchを備えた4コアXeonです。 すべてのトラフィックはローカルです。 ハードウェアの詳細には触れませんが、構成の詳細も多かれ少なかれ標準です。

最初に、1000クエリのテストサイクルを次々に実行します。

# Apache 2.2.14 (prefork) + PHP 5.2.12 (module)<br/>ab -n 1000 http://localhost:8085/hello.php<br/>Time per request: 5.278 [ms] (mean, across all concurrent requests)<br/># nginx (1 worker) + javascript<br/>ab -n 1000 http://localhost:8081/hello.jsx<br/>Time per request: 1.298 [ms] (mean, across all concurrent requests)<br/># nginx (8 workers) + javascript<br/>ab -n 1000 http://localhost:8088/hello.jsx<br/>Time per request: 1.322 [ms] (mean, across all concurrent requests)<br/>
100の同時接続を作成するときに、1000リクエストのテストサイクルになりました。

# Apache 2.2 (prefork) + PHP 5.2 (module)<br/>ab -n 1000 -c 100 http://localhost:8085/hello.php<br/>Time per request: 1.648 [ms] (mean, across all concurrent requests)<br/># nginx (1 worker) + javascript<br/>ab -n 1000 -c 100 http://localhost:8081/hello.jsx<br/>Time per request: 1.277 [ms] (mean, across all concurrent requests)<br/># nginx (8 workers) + javascript<br/>ab -n 1000 -c 100 http://localhost:8088/hello.jsx<br/>Time per request: 0.544 [ms] (mean, across all concurrent requests)<br/>
テスト結果：

• サーバーへのリクエストが次々と連続して送信される場合、nginx + javascriptははるかに高速です（約3倍あります）。 同時に、1つのワークフローを備えたnginxは、少し速く動作します。 実際には、この状況はほとんど発生しません。多くの場合、多くのクライアントが同時に異なるページを開きます。
• サーバーへのリクエストが同時に送信されると、apache + phpの速度が向上します（1つのワークフローでnginx + javascriptとほぼ同じ速度を示しました）。 しかし、いくつかのワークフローでのnginx + javascriptの速度も向上します（私たちの場合-2倍以上）。 そして、1つのワークフローを備えたnginx + javascriptはほとんど変わりませんでした

このようなサーバーサイドjavascriptの実装により、従来のPHPと比較して生産性が向上するという事実に加えて、javascriptでは非常に巧妙な言語構成を使用できます。

// id GET, POST cookies:<br/>print($request.get['id'], " ", $request.post['id'], " ", $request.cookie['id']);<br/>// Content-Type:<br/>$result.headers.push("Content-Type: text/html; charset=UTF-8");<br/>// , SELECT , GET, :<br/>var row = (new SQLite("database")).query("SELECT * FROM `table` WHERE `id`=?", $request.get['id']).fetch();<br/>// :<br/>print(File.open("index.html").getChars());<br/>// IP- , :<br/>print({$server.remoteAddr});<br/>
最後の例には構文エラーはありません; XMLドキュメントは実際にスクリプト内で使用できます。 同時に、変数呼び出しと関数呼び出しをそれらに挿入して、それらを中括弧で囲むことができます。 このテクノロジーE4Xは 、テンプレートの作成に非常に便利です。 他の多くの例は、 http：//js.nnov.ru/nginx/examples.htmlにあります。

もちろん、次第に解決する必要がある多くの問題があります。

• ファイルダウンロードサポート（近日公開！）
• cURLとGDのサポート。これなしでは、生きることは非常に困難です。
• ファイルへの実際のパスを決定するために使用されるstat（）システムコールの最適化

ただし、一般的には使用できます。 ちなみに、小さなサイトhttp://js.nnov.ruがJavaScriptで作成されています。 フォールトトレランスのハードテストはまだ行わないでください:-)

ZY>招待してくれたFTMに感謝します。そのおかげで、トピックはサンドボックスにありません
UPD>テーマをすぐに公開しますが、カルマに問題がありました。 関係者全員に感謝します！