Web アプリケーションのパフォーマンスに関心のある人なら誰でも、 Facebook の BigPipe の背後にある考え方を知っています。
最近、Symfony はfragment サブフレームワークと呼ばれる新しい機能をリリースしました。
この機能の背後にあるアイデアは、ESI 言語仕様 1.0として W3C に説明されている ESI テクノロジを使用することです。
私の質問は、Facebook の BigPipe は、この ESI テクノロジに何らかの形で関連していますか? ESI を使用して BigPipe のアイデアを実現できますか?
おそらく、独自の ESI サーバーの実装がなければ、パフォーマンス ヒットの価値があるかどうかは疑問です。
BigPipe の記事を正しく理解していると仮定すると、サーバー側で行う必要があるのは、a) 静的 HTML コンテンツをクライアントにすぐにフラッシュし、b) いくつかのレンダリング スレッドを非同期に開始し、スレッドがレンダリングを終了するたびに出力をフラッシュすることだけです。残りは JavaScript マジックであり、サーバー側のフレームワークとは何の関係もありません。
symfony は単純な HTML ドキュメントをレンダリングし、そこに ESI タグを含めることができるため、a) がカバーされます。ただし、ESI はタグが検出される順序に依存します。これは、ほとんどのキャッシュ サーバーがすべての ESI タグの処理を非同期的に開始すると思われますが、特定の順序でしか出力をフラッシュできないことを意味します。つまり、最初の ESI タグが遅いと、他の「ページレット」がユーザーにフラッシュされなくなります。
これが、インクルードがドキュメントのどこに表示されるかを完全に無視しながら、インクルードを非同期に取得できる特別な種類のキャッシュ サーバーが必要になると私が考える理由です。
他の大きな欠点は、各 ESI タグが独自の HTTP リクエストを symfony に引き起こし、リクエストごとにかなり大きなセットアップ オーバーヘッドが発生することです。
結論として、ESI はキャッシュされたページを返したい場合に優れていますが、生成にコストがかかり、キャッシュできないコンテンツがわずかに含まれていますが、BigPipe の実装には適していない可能性があります。