👇🏻 🤽🏾 🤟🏾 サーバー上のJavaScript、変換ごとに1ミリ秒 👇🏽 👨‍❤️‍👨 🏬

なんで？

「なぜ」という質問は、決定を下す際に最も重要です。私たちの場合、いくつかの理由がありました。

まず第一に、人々。現在のテンプレートエンジンはCによって処理されました。彼の変更に関するすべての質問はすぐに解決されませんでした。そして最も重要なことは、テンプレートエンジンを書いた人もいますが、まったく別の人がそれを使用しました。

一般に、これは頻繁に行われるものであり、私の意見では、レイアウト設計者向けのツールを書くことはあまり良い習慣ではありません。ツールが必要であることは明らかですが、レイアウト設計者の日常のタスクを非常にリモートで想像している人は、これらのツールを理解しています。むしろ、それどころか、「条件とサイクルを書かせて、レイアウトにこれ以上何も必要ないようにする」という計画の決定がしばしば下されます。おそらく、これはレイアウト設計者自身と彼らの資格のせいです。

しかし、Mail.Ru Groupには、JSを知っており、自分でツールを書くことができる有能な人々のチームがあり、最も重要なのは、それを使用することです。

第二に、タスク。プロジェクトMail@Mail.ruを取ります。サーバーでのテンプレート作成を拒否することはできません。最初のログインで高速にロードする必要があります。クライアントの標準化を拒否することはできません。ユーザーは自分の行動に対する高い反応率を確認する必要があります。つまり、クライアントのAJAXと標準化が必要です。

問題は明らかです。サーバーとクライアントで完全に異なるテンプレートの2つのセット。そして、最も不快なのは、彼らが同じ問題を解決することです。ロジックの複製は私たちを疲れさせました。

v8はJavaScriptインタープリターです。つまり、サーバーとクライアントの両方で機能する1つのテンプレートを取得できます。

第三に、スピード。 v8の速度を称賛する多くの記事を読んだ後、私たちはそれらの公平性を検証する必要があると判断しました。しかし、最初に、新しいテンプレートエンジンをどのように見たいかを理解する必要がありました。

必要なもの

変換のためのサーバー時間は非常に限られているため、非常に機能的なものに気付くことはありませんでした。ただし、v8からレイヤーを追加する点で唯一の違いを残して古い機能を残すのは奇妙な考えです。

私は長い間XSLTを頻繁に使用しています（変換の最速バージョンではありません）が、正しく使用すると、良い数値を示します（libxsltについて話している）。ただし、XSLTにはテンプレートの再定義という非常に強力なテンプレートツールがあります。類似したものを実装することにしましたが、はるかに簡単です。

/head.xml … <title><fest:get name=”title”/></title> <fest:set name=”title”>Mail.ru</fest:set> /mail.xml … <fest:include src=”head.xml”/> <fest:set name=”title”> Mail.ru</fest:set>

v8を使用し、テンプレートへのJavaScriptアクセスを許可しないのは奇妙です。

 <fest:script> var text = “mail.ru” </fest:script> <fest:value>text</fest:value>

そして、標準的な条件とサイクルに加えて、ささいなことについてはもっとたくさん。

XML

テンプレートエンジンの構文としてXMLを使用しました。

IDEの基本機能のサポート。人気のあるIDEの100％がXMLを知っています。ハイフネーション、バックライト、基本的なオートコンプリートは無料です。

IDEレベルの検証。有効なHTMLは、有効なテンプレートから取得されます。繰り返しますが、すべてのIDEはxml自体を検証できます。

すぐに使えるモジュラリティ（名前空間）。テンプレートエンジンの基本機能は、非常に迅速に拡張する必要があります。たとえば、複数の言語でプロジェクトを実行できるタグを追加します。名前空間を使用すると簡単になります。

幅広い市販のツール。長年にわたって、XMLを処理するための多くのツールが蓄積されてきました。たとえば、XSLまたはSAXパーサーのクラス全体を使用してXMLを処理するためのライブラリ、検証用のXSDおよびDTDスキームなどです。

処理構造の構文と結果の構造の一致。言い換えれば、XMLからXMLへの作成は便利であり、フェストテンプレートは読みやすいです。さらに、すべてのデータシールドの問題が解決されました。

実装

カウボーイ私自身、最近そのような用語があることを知りました。

それ以前は、タスクを完了するための最も信頼できる方法は、プログラミングとテストのペアであると確信していました。いつものようにテストは報われましたが、ペアリングプログラミングが代替手段を見つけました。

このタスクと典型的なタスクとの違いは、テンプレートと、このテンプレートが生成する結果のHTMLです。 Kostya（Frontend Mail Developer）と私は独自の実装を書き始めました。週に一度、変換速度の測定値を比較しました。

私たちは2つの異なるアプローチを選択しました。彼はテンプレートを関数にコンパイルし、私は構造にコンパイルしました。最も単純な構造の例：

 01 [ 02 {action:"template"}, 03 "<html>...", 04 {action:"value"}, 05 "json.value" 06 ]

2行目は、パターンの始まりを示しています。 3つ目は、単にブラウザに渡すことです。 4つ目は、5つ目はJavaScriptとして実行する必要があり、実行結果はブラウザに渡す必要があることを示しています。

 01 [ 02 {action:"template"}, 03 "<html>....”, 04 {action:"if"}, 05 "json.value", 06 "<span>true</span>", 07 "<span>false</span>" 08 ]

オプションはもう少し複雑です。 4行目は、5行目を実行する必要があることを意味し、結果がtrueまたはfalseの場合、それぞれ6行目または7行目を指定します。

この機能を備えたオプションは、特に説明する必要はありません。

 01 function template(json){ 02 var html = ""; 03 html += "<html>…"; 04 html += json.value; 05 return html; 07 }

今後は、彼のバージョンの方が速かったと思います。しばらくの間、私たちはほぼスムーズに歩きましたが、構造を備えたバージョンははるかに早く天井に達しました。

私がこのアプローチを与えたことを理解するために：私の最初の実装はタスクを200ms完了しました。可能なすべてを絞り出して、2つのプログラムのベストを組み合わせたとき、3ミリ秒になりました。

現在の実装を簡単に説明すると、サイクルをサイクルに、条件ステートメントを条件ステートメントなどに変換します。

 fest:foreach for(i = 0; i < l; i++) {} fest:if if(value) {} fest:choose if(value) {} else {}

コンテキストの絞り込みはありません。はい、これは制限ですが、コンテキストを制限するためのオーバーヘッドはありません。最も重要なことは、コンテキストを絞り込むとすぐに、グローバルコンテキストまたはコンテキストからレベルを上げるタスクがすぐに発生することです。

テンプレートが厳格モードで動作するJS関数に変換されることが重要です。これは、メモリリークにつながるコードを作成する機会をコーダーに与えません。

データを論理的に処理する必要がある場合はいつでも、JavaScriptを使用できます。

 <fest:if test=”_javascript_”></fest:if> <fest:value>_javascript_</fest:value>

JavaScriptを含むすべての構成体は、try catchにラップされます。

JavaScriptの実行後にHTML出力を前提とするすべての構成は、デフォルトでHTMLエスケープになります。

 <fest:value>json.name</fest:value>

 try { html += __escape(json.name) } catch(e) {}

テンプレートエンジンの開発は、最初からオープンな形で行われてきました。

https://github.com/mailru/fest

統合オプション

一方、v8はJavaScriptを解釈できるライブラリにすぎません。それ自体では、役に立たないようです-システムにアクセスできません。しかし、一方で、他の言語に簡単にねじ込まれます。

CおよびPerlプログラミングの経験がないため、両方の言語でテストケースを作成しました。さらに、現時点ではPythonがたくさんあります。

そしてもちろん、プロトタイプとブラウザー用のNodeJSは、JavaScriptテンプレートがそのまま使用できる環境です。

戦闘条件に近い

3msを受け取った後、サーバー側のプログラマーに行きました。ユーザーのメールのリストを送信するリクエストにどれだけの時間があるかを尋ねられたとき、彼らは言った：4ms以下。変換にはすでに3msありましたので、試してみました。

私たちが持っている文字のリストは、Cで書かれた独自のhttpサーバーによって与えられます。データ取得-プロセッサと競合しない操作なので、測定されませんでした。変換用のデータの準備と変換自体は停止しました。

歴史的な理由から、httpサーバーはデータをフラットハッシュに保存します。

 msg_length = 5 msg_1_title = “letter” msg_1_Unread = 1

JavaScriptについて話しているので、最初に思い浮かぶのはJSONです

 msg = [ {title: “letter”, Unread: true} ]

テンプレートをv8に変換するときにJSONを使用してJavaScriptを操作すると、フラットハッシュの行をメモリに入れて結果を出し始めました。

私たちは多くのオプションを試しました。オブジェクトを転送し、文字列を転送してJavaScriptで解析し、文字列を転送してJSON.parseに渡します。

奇妙なことに、フラットハッシュをJSONに一致する文字列に変換し、v8に文字列を与えるのが最速であることが判明しました

 “template([ {title: \“letter\”, Unread: true} ])”

しかし、すべてにもかかわらず、2ミリ秒の変換で6ミリ秒になりました。誰もがgiveめる準備ができていました。それでも、ソースデータ、フラットハッシュを含む行を取得し、同じコンパイル済みテンプレートを使用して、NodeJSで必要なHTMLを取得することにしました。

4ミリ秒。この番号でシシニコフに来たとき、「クールですが、NodeJSには書くリソースがありません」というフレーズを正直に期待していましたが、代わりに「NodeJSが4msでできるなら、私たちもできます！」

その瞬間に気付いたのは、これを本番環境に持ち込むことです。第二の風がありました！

解決策は簡単でした。データの準備に時間の67％を失い、原則として既にデータを持っているので、データの準備を捨てる必要があります。

__get（ 'key'）関数をv8に投入しました。したがって、v8からは、httpサーバーのハッシュから直接データを取得しました。目的の形式へのデータ変換はありません。この文字列からv8内のオブジェクトへの変換はありません。 3ミリ秒で出発し、1ミリ秒の予約がありました。

ほぼ生産

だから、すべてが素晴らしく見えますが、私たちも生産に近づいていませんでした。手がかゆみしてみてください。

別のサーバーを用意し、v8で動作するhttpサーバーのバージョンを上げて、実際のリクエストを複製します。 2.2 GHz Xeonのコアを30時間放置します。

 10,000,000件以上のヒット
平均変換時間1.6ms

 992 422 2〜5ミリ秒の10％
 208 464 5〜10ミリ秒の2％
 10ミリ秒以上39 649 0.4％

2msを超えるのはわずか12％でした。 v8はメモリから安定して動作します。

生産

私は最後の数字で副テクニカルディレクターに来て、v8は生産の準備ができているので、別の小さなプロジェクトを作成する必要があり、失敗した場合には忘れてしまう可能性があります。これに応えて、彼は「数字は良好で、失敗がひどくない別のプロジェクトは正しいですが、本当にv8を立ち上げたいですか？」 Mail.Ruホームページから開始します。質問は正しく提起されています-私たちはビジネスをしている、または傍観者を楽しんでいます。

フェストのメインページのレイアウトには3日かかりました。バランサーから1つのサーバーの電源を切り、バージョンをv8でアップロードし、リクエストを複製しました。すべての計算は、単一のデーモン/カーネルのコンテキストで行われます。

さらに、良い結末で非常に有益な話をします。

グラフの表示内容を常に詳細に確認してください。テストサーバーに半分の負荷をかけます。 CPU消費は通常の3倍でした。これは、現在のテンプレートエンジンと比較して、リソースの6倍の損失という障害のように見えました。

彼らは見始めました。ここでは、メインアーキテクチャについて少し説明します。さまざまなプロジェクトから情報を収集します。内部開発を収集し、RBと呼びます。メインを返すために生成される165kbのうち、100kbがRBを収集します。そして、次のことが起こります：RBはHTMLピースをv8のhttpサーバーを通して送信し、v8はそれらを独自の文字列で連結し、結果はこれらすべてをhttpサーバーに返します。

二重データ転送があります。最適化されました。 v8では、RBからのデータを含む1つの大きな行を構築する代わりに、データを直接httpサーバーに送信します。

 __push_string('foo'); __push_rb(id); __push_string('bar');

さらに、v8には文字列の連結がなく、サーバーからv8へ、またはその逆へのダブルRB転送はありません。最も重要なことは、データ転送はutf-8からutf-16へ、またはその逆への変換です。 V8はすべてをutf-16に保存します。

利益があり、リソースは3つではなく通常の2倍に消費されました。つまり私たちはまだ4回負けていましたが、すべてを絞ってしまったように見えました。

そして今、有益な部分。興味を引くために、テストした負荷に、マシン上の悪魔の数とマシンの数の2を掛けました。 4億4千万件のヒットを受けました。さらに、1日あたり1億1,000万件のヒットがあります。曖昧な疑いが忍び込んだ。

ログを見てみましょう。負荷のあるリクエストごとに、統計のログにレポートを含む3つのリクエストを受け取ったことが判明しました！ 1つのhttpサーバーの実際の負荷は、テスト対象の4倍です。

翌朝、v8のメインページのバージョンを公開しました。

今日のデータ：

v8が生成するHTMLのサイズは65kbです。

時間、リクエスト1msあたりv8の作業。

平均して、v8ではコンテキストごとに40MBが必要です。

いくつかの説明

v8について考えているすべての人が、Igor Sysoevによる記事を見つけましたsysoev.ru/prog/v8.html

このタスクに取り組んでいる間ずっと、v8開発者Vyacheslav Egorov（http://mrale.ph）が私たちを大いに助けてくれました。

記憶の恐怖は正当化されます。正しい操作が重要な場合（メモリ不足が通常の状況である場合）、問題が発生します。割り当てエラーを正しくキャッチできますが、これについてできることは、正しく再起動することだけです。

しかし、正直に言うと、重要な製品は1つだけです。メインページについては、大量のメモリがあり、非常によく監視しています。

v8トランクが流れていることがわかりました。 Vyacheslavはこれを再現できませんでしたが、開発者がリークを発見するのに役立つテストケースをまとめると思います。バージョン3.6はメモリから正常に動作します。

便利なリンク

-github.com/mailru/festテンプレートエンジン

-code.google.com/p/v8 v8 API

-Igor Sysoevによるsysoev.ru/prog/v8.html記事

Andrey Sumin、開発部長、クライアントパートMail.ru

サーバー上のJavaScript、変換ごとに1ミリ秒