2014年の初めに、デザインを統一するタスクがコンテンツプロジェクト部門にやってきました。 設計者は、統一されたスタイルのプロジェクトとインターフェイスの操作原理を求めていました。 ユーザーにとって便利であり、新しいプロジェクトの立ち上げと既存のプロジェクトの再設計を容易にします（Yura Vetrov がこれについて詳しく書いています）。 フロントエンドチームは、異なるプロジェクトで同様の組版コンポーネントを使用する機会があります。これにより、既存の機能の開発とサポート時間が短縮されます。 バックエンドチームにとって、タスクは簡単なものではありませんでした。ほとんどのプロジェクトはPerl（テンプレートツールキット）、PHPの不動産、Children and HealthでDjangoを使用して書かれています。 しかし、単一のテンプレートエンジンのサポートを実装するだけでなく、テンプレートに送信されるデータの単一の形式に同意する必要がありました。 ロード可能なAJAXブロックが豊富であるため、クライアントの標準化もサポートする必要がありました。



したがって、デザインを統一するタスクは、Perl、Python、PHP、JSの単一のテンプレートエンジンを選択するタスクになりました。

最初のステップ

タスクは複雑に見え、完全に解決されていないため、さまざまなオプションを探し始めました。 既製のソリューションから始めました。 最初のアイデアは、Django Dotiac :: DTLテンプレートエンジンをPerlに、またはテンプレートツールキットをPythonに移植することでした 。 テンプレートツールキットを使用すると、テンプレートでプログラムロジックを記述できます。これにより、他の言語では使用できなくなります。 Djangoテンプレートはテンプレートでのプログラミングを大幅に制限しますが、フィルターとタグの形式で拡張機能を拒否するか、PerlとJSでロジックを複製する必要があります。 さらに、移植されたバージョンがどの程度機能するかは不明です。 したがって、このアイデアは、テンプレートエンジンの基本的な構造（if / else条件のブロック、forループ、包含を含む）の使用に帰着しました。 このため、完全なポートは必要ありません。 使用したいが、何らかの理由で（たとえば、別の言語で実装されていない、または異なる方法で実装されている）機能は、プロセス全体に干渉するだけです。 したがって、パフォーマンステストに到達しませんでした。 このアイデアは延期されました。



2番目のアイデアは、 Mustacheを使用することでした。 このテンプレートエンジンは、Webで人気のある（PHP、Python、Perl、Ruby、JS）から非常に遠い（R、Bash、Delphi）まで、多くの言語で利用できます。 テンプレートにロジックがないことは、最初は魅力的でした。テンプレート制御用のデータを準備するプロセスは、バックエンドを完全に制御し、テンプレート自体にはロジックがありません。 しかし、これは不必要な極端であることが判明しました。 データの準備には時間がかかりすぎたようで、パーシャルメカニズムは不便で、テンプレートコレクターが必要でした。 「私の意見では、これは地球上の地獄の断片です」というフレーズと一緒に、口ひげを考えることをやめました。



また、必要なすべての言語で独自のシンプルなテンプレートエンジンを記述する、または必要なテンプレートを作成できるメタ記述を作成するというアイデアもありました。 タスクは面倒でしたが、オプションの検索を続けました。

フェスト

Festは、XMLテンプレートをJavaScript関数にコンパイルするテンプレートエンジンです。 当時、すでにモバイル版でfestを使用した経験がありました。 大きなバージョンとの主な違いは、その時点では検索ボットはモバイルバージョンにほとんど注意を払っていなかったことであり、サーバーリソースを節約しながら、クライアント上で完全にテンプレート化する余裕がありました。 HTMLページでは次のようになりました。

<script> document.write(fest['news.xml'], context) </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテキストはJSONシリアル化データです。 レンダリングされたHTMLは、document.writeを介してページに出力されました。



festを使用すると、クライアント上のテンプレートの問題が解決されるため、サーバーでこのJSを実行する方法を学ぶ必要がありました。 フロントエンドチームもこのオプションをサポートしていました。 サーバーでJavaScriptを実行するために、Googleから人気のあるV8を選択しました。 V8は急速に開発されていますが、継続的な「パフォーマンスと安定性の改善」により、マイナーバージョンでも下位互換性が損なわれることがよくあります。 これは理解できます。V8は主にChrome（古いバージョンの代わりに新しいバージョンが付属するブラウザー）向けに開発されています。 V8の使用を開始し、Mailの同僚の経験を活用しました。

V8

まず、既製のソリューション、 つまり PythonとPerlのバインダーを探し始めました。 パッケージのアセンブリに少し苦しめられて（V8はバインディングよりもはるかに先を行き、互換性のあるバージョンを見つけるのは容易ではありませんでした）、私たちはそれらを試し始めました。 コンテキストの高額な引き上げにすぐに気付きました。コンテキストの作成には約10ミリ秒かかり、テンプレートのレンダリングには20ミリ秒かかります。 したがって、コンテキストはリクエストごとに1回作成し、理想的には後で再利用する必要があります。 そのため、一般的なコンポーネントのレンダリングをネイティブテンプレートエンジン（TemplateToolkitまたはDjango）に組み込むことには疑問がありませんでした。 あなたは完全に祭りに行かなければなりません。



これらのバインディングは非常に信頼でき、プロジェクトが開発され、使用例がインターネットで公開されました。 そして、私たちはそれらを使い始めました。 当時、Auto（Perl）およびHealth（Python）プロジェクトは再設計されていましたが、新しいテクノロジーをテストしました。 コントローラーで、コンテキストを形成し、それをJSONにシリアル化し、ロードされたテンプレートに送信しました。

 ctx = PyV8.JSContext() with ctx: ctx.eval(template) ctx.eval('fest["%s"](%s)' % (fest_template_name, json_context)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは有効なオプションでしたが、それほどバラ色ではありませんでした。 実際には、テンプレートに加えて、一般的なヘルパーユーティリティがあります。 それらは一度V8にロードされ、ページのレンダリング時に使用される必要があります。 V8上のラッパーはそのようなコードをロードできましたが、これを厳密に1回行う必要がありました。 再読み込みの結果、メモリリークが発生しました。 テンプレートコードでも同じことが起こりました。 その結果、各リクエストに対してコンテキストが作成され、その後コンテキストが削除されました。 パターン化は遅く、プロセッサリソースは無駄になりましたが、メモリは流れませんでした。 しかし、すべてがほぼ安定して動作しました。 その結果、この図で自動が開始されました。



V8上のラッパーを使用すると、JavaScriptコンテキストで言語オブジェクトを使用できます。 しかし、PyV8の場合、これはまったく機能しません。 私が試したすべてのバージョンは、すぐにメモリをリークまたはクリアしましたが、セグメンテーション違反に陥りました。 バインドは転送されたオブジェクトのタイプを正直にチェックするため、純粋にJavaScriptの実行にいくらかのオーバーヘッドを伴うバインダーの使用が削減されました。 健康に関しては、戦闘でPyV8を使用することはもうありませんでした。



一方、郵便局の同僚は彼らの決定を共有しました。 これは、テンプレート名とコンテキスト（JSON文字列）を受け取り、ユーザーに提供するHTMLを返す独立したリビングデーモンです。 多くの方法で、彼は私たちの問題を解決します。 デーモンは起動時に共通ヘルパーをロードし、テンプレートをメモリにキャッシュし、速度とメモリが安定して動作します。 それでも、これは理想的な解決策ではありませんでした。 メールは、私たちとは異なるタスクのためにこのツールを開発しました。 それらのパターンは私たちのものよりもはるかに小さくて軽く、より速く実行されます。 以前、Andrei Suminは標準化のために約1ミリ秒（ サーバー上のJavaScript、変換のために1ミリ秒）を書いていました。平均15-20ミリ秒です。







彼らのソリューションは、サーバーごとにテンプレートデーモンの1つのプロセスを必要とします。 同僚はマルチプロセッサバージョンを作成しましたが、解決策が必要な問題は残っていました。

1. 自立型デーモンには安定した動作が必要です。 バックアップサーバーにすばやく切り替えるには、彼の作業を監視する必要があります。
2. エラーのあるログは、表示されるページのアドレスとは関係ありません。
3. ログは、一般的な統計収集システムではなく、ファイルに書き込まれます。
4. 遅延を回避するには、同じ数のバックエンドワーカーとテンプレートデーモンが必要です。

興味深いケースもありました。 テンプレートに入れられると、永遠のサイクルが誤って発生し、労働者を完全に占有し、これは悲惨な結果をもたらしました。 このようなケースは今後発生しませんでしたが、このようなエラーに対する保護はありませんでした。 その結果、健康はこのスキームから始まりました。 しかし、私たちはそこで止まりませんでした。 次のステップは、別のデーモンを放棄することでした。私たちは、PerlとPythonの実行可能プロセスにテンプレートを組み込むことにしました。 その結果、 V8の一般的なラッパーが作成され、JSファイル（ヘルパーとテンプレート）を読み取り、メモリにコードをロードして実行（つまり、テンプレートをHTMLでレンダリング）することができました。







このモジュールは、プロセスに対して1つのV8コンテキストを生成し、その中ですべてのさらなる作業を実行します。 このアプローチの結果、ライブラリの名前が生まれました-V8MonoContext。 次に、言語コンテキストでこれらの関数を使用して、PerlでXSモジュールとPythonの拡張機能を作成しました。

 renderer = MonoContext() renderer.load_file(utils_file) append_str = 'fest["{}.xml"]( JSON.parse(__dataFetch()) );'.format(bundle) html, errors = renderer.execute_file(template_file, append_str, json_str)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヘルパーは、load_fileメソッドを使用してプロセスの開始時に1回ロードされます。 execute_fileメソッドは、テンプレートをロードし、テンプレート関数を呼び出します。テンプレート関数には、テンプレートのデータを含むJSONが渡されます。 その結果、HTMLと、バックエンド自体の標準ツールを介してログに記録される可能性のあるエラーのリストを取得します。 今、このソリューションは完全に私たちに合っています：

1. パターン化は、単一のワーカー内でユーザーリクエストを処理するための不可欠な部分です。 所要時間を測定し、考えられるエラーを記録できます。
2. V8コンテキストは、ワーカーの開始時に一度上昇します。
3. JSコードが一度ロードされると、サーバーリソースが最適に消費されます。
4. V8は、ネイティブ言語のテンプレートエンジンよりも多くのメモリを消費します。 ワーカーの常駐メモリは、平均で200 MB増加しました（最大300 MB）。
5. また、スレッドモードはサポートされていません。これは、Pythonプロジェクトに関連する可能性があります。 1つのプロセス内で実行できるコンテキストは1つだけであり、この時点では残りは非アクティブになっている必要があります。 これが、ChromeでのV8の機能です。 しかし、これはわずらわしいことではなく、プリフォークモードで動作します。

GCに関連するV8の他の機能があります。 V8は、通常メモリが不足し始めた場合に、適切であると判断しながらガベージコレクタを起動します。 これに対応するには、2つの方法があります。

1. RAMを確保し、V8を完全に信頼します。 V8コンテキストは、設定値MaxRequestを介してワーカーと共に停止します。
2. 一定の周期で、「ハンドル」を実行します-低メモリLowMemoryNotificationについてのシグナル。 まれに起動すると、クリーニング時間が長くなり、余分なプロセッサリソースが頻繁に使用される恐れがあります。 テンプレート作成リクエスト500件ごとにLowMemoryNotificationを呼び出します。

V8に割り当てられたメモリのサイズを制限することもできます（V8のメモリ管理フラグ ）。 この場合、GCはより頻繁に開始されますが、解決する方が速くなります。 十分なメモリがない場合、サーバーはスワップ内のヒープの一部を遅延させる可能性があり、これにより追加の遅延が発生します。 その結果、この図にポスターが掲載され、結果は完全に満足しました。 すぐに、V8MonoContextはPHPでの作業を学び、その後、他のプロジェクト（自動車、星占い、健康、女性、不動産、天気、ハイテク）を学びました。

性能比較

V8のテンプレートエンジン（および他のアクティブなテンプレートエンジン）の速度は、処理するデータ量と適用されるロジックに依存することに注意してください。 純レンダリング時間は、合成テストによってのみ決定できますが、これは必ずしも実際の状況を反映しているとは限りません。 私たちの場合、V8からの移行は再設計で行われたため、正確な測定値はありません。 メトリックを間接的に比較すると、最大2倍の利益が得られました。

開発アプローチ

フェスティバルへの移行に伴い、開発へのアプローチが変わりました。

1. 共通のテンプレートコンポーネントには、それを使用するプロジェクト用の単一のインターフェイスが必要です。 これには、プロセスのすべての参加者の特定の順序と調整が必要です。 私たちはドキュメントの中で、フロントに送信されるデータの形式を説明し始めました。 さらに、CSRFトークンを使用するなど、さまざまなバックエンド（Perl、Python、PHP）向けの一般的なシステムソリューションを開発しています。
2. 共通のコンポーネントはすべてのプロジェクトで異なるため、迅速かつ効率的に機能することが特に重要です。
3. バックエンドがデータを返し、テンプレートにまったく触れない純粋なMVCスキームがあります。 フロントに十分なデータがない場合は、バックエンドを待つ必要があります。

結論

Perl、Python、およびPHPの単一のテンプレートエンジンに切り替えるタスクを解決しました。 一般的なコンポーネント（コメント、ギャラリー、投票など）を迅速に実装し、すべてのプロジェクトに分散できるようになりました。 私たちにとって、クライアントの標準化は大きなプラスになりました。現在、ロジックをクライアント側に転送することは実質的に価値がありません。 このシリーズの次の記事は、フロントエンドからの記事で、同僚が既に準備しています。