高速Webアプリケーション-Web Trepanation

心理学は興味深く、時には役に立つ科学です。 多数の調査によると、300ミリ秒以上にわたってWebページの表示が遅れると、ユーザーはWebリソースから注意をそらし、「一体どうしたの？」と考えるようになります。 したがって、Webプロジェクトを心理的に知覚できない値に加速することにより、ユーザーをより長く保つことができます。 そして、それがビジネスが速度にお金を費やす準備ができている理由です：$ 80M-わずか1 msだけレイテンシーを削減します



ただし、最新のWebプロジェクトを高速化するためには、kroushkaにこのトピックを徹底的に掘り下げる必要があります。したがって、ネットワークプロトコルの基本的な知識は大歓迎です。 原則を知っていれば、わずかなアプローチでWebシステムを数百ミリ秒で簡単に高速化できます。 さて、数億を節約する準備はできていますか？ コーヒーを注ぐ。

後味

これは非常にホットなトピックです-サイトのユーザーを満足させる方法-そして、ユーザビリティ主義者はおそらく私にモロトフカクテルを飲ませ、小切手なしで手ade弾を噛ませ、爆発の前に叫ぶ時間を与えます：「私は異端を運んでいます。」 したがって、私は反対側から行きたいです。 ページの表示の遅延は0.3秒以上であることが広く知られています。これにより、ユーザーはこれに気づき、サイトとの通信プロセスから「目覚め」ます。 そして、表示の遅延は1秒以上です。トピックについて考えると、「ここで何をしているのですか？ なぜ彼らは私を拷問し、私を待たせているのですか？」

したがって、私たちは彼らの「使いやすさ」に使いやすさを与え、実用的な問題に対処します-クライアントの「夢」を妨げず、「ブレーキ」に気を散らすことなく、できるだけ長くサイトで彼の仕事を促進しないか。

スピードの責任者

まあ、もちろんあなたは誰ですか。 そうでなければ、あなたはほとんど記事を読み始めませんでした。 真剣に、問題があります-速度の問題は、技術的および社会的に緩やかに接続された2つのフロントエンドとバックエンドに分かれています。 そして、彼らはしばしば3番目の重要なコンポーネントであるネットワークを忘れます。

HTMLだけ

まず、90年代前半の最初のサイトは静的なページのセットだったことを思い出してください。 また、HTMLはシンプルでわかりやすく簡潔でした。最初のテキスト、次にテキストとリソースです。 Bacchanaliaは、Webページの動的な生成とjava、perlの普及から始まりましたが、今日では、すでにPHPを含む技術の銀河です。
この競争がネットワークの実行可能性に与える影響を軽減するために、1996年にHTTP / 1.0に従い、3年後-1999年にHTTP / 1.1になりました。後者では、TCPハンドシェイクを光の速度の約2/3で駆動する必要がないことに最終的に同意しました光ファイバー）各要求に対応し、新しい接続を確立するか、TCP接続を一度開いて処理します。

バックエンド

アプリ

ここ40年間でここでほとんど変化はありません。 おそらく、 NoSQLという名前でリレーショナル理論の「パロディ」が追加されました。これは長所と短所の両方をもたらします。 しかし、実践が示すように、それはビジネスからより有益であると思われます（ただし、「整合性データを誰がどのような口実で奪ったか」という質問への回答を含む眠れぬ夜は、より可能性が高くなりました）。

1. アプリケーションおよび/またはWebサーバー（php、java、perl、python、rubyなど）-クライアント要求を受け入れます
2. アプリケーションはデータベースにアクセスし、データを受信します
3. アプリケーションはhtmlを生成します
4. アプリケーションおよび/またはWebサーバー-クライアントにデータを送信します

ここでは速度の点ですべてが明確です。

• 最適なアプリケーションコード、数秒間ループなし
• データベース内の最適なデータ、インデックス付け、非正規化
• データベースサンプルのキャッシュ

「アプリケーション」のオーバークロックについてはもう説明しません。多くの本や記事が書かれており、すべてが非常に直線的でシンプルです。
主なことは、アプリケーションが透過的であり、アプリケーションのさまざまなコンポーネントを介してリクエストの速度を測定できることです。 そうでない場合は、さらに読むことはできません、それは助けにはなりません。
これを達成する方法は？ パスは既知です：

• 標準リクエストのロギング（nginx、apache、php-fpm）
• 遅いデータベースクエリのロギング（mysqlのオプション）
• リクエストを渡す際のボトルネックを修正するためのツール。 phpの場合、これはxhprof、pinbaです。
• 別のトレースモジュールなど、Webアプリケーション内の組み込みツール。

大量のログがあり、それらで混乱している場合-集計データ、パーセンタイルと分布を参照してください。 シンプルでわかりやすい。 0.3秒以上のリクエストが見つかりました-最後までデブリーフィングを開始します。

Webサーバー

引っ越します。 Webサーバー。 ここでは、ほとんど変更はありませんが、Webサーバー（fascgiサーバー）の前にリバースプロキシWebサーバーをインストールすることで、松葉杖が発生する可能性があります。 はい、確かに役立ちます：

1. クライアントとのより多くのオープンな接続を維持するために（犠牲になりますか？..はい、キャッシングプロキシの別のアーキテクチャ-nginxの場合、これは1つの接続に少数のプロセスと低メモリによるソケット多重化を使用します）
2. アプリケーションコードをフィルタリングせずに、ディスクから静的リソースを直接効率的に提供します。

しかし、疑問は残っていました。なぜ彼らはすぐに「正しく」 Apacheを始めなかったのですか。時にはWebサーバーを電車に乗せる必要があります。

永続的な接続

TCP接続の確立には1 RTTかかります。 チャートを印刷して、あなたの前でハングアップします。 ブレーキの外観を理解する鍵はここにあります。

この値は、Webサーバーに対するユーザーの位置と非常に密接に相関しています（はい、光の速度があり、マテリアルに光の伝搬速度があり、ルーティングがあります）、数十または数百ミリ秒かかることがあります（もちろん、非常に多いです） 。 そして、問題は、この接続がリクエストごとに確立される場合です。これはHTTP / 1.0で一般的でした。



このため、HTTP 1.1は概して開始され、 HTTP 2.0 （ spdyで表される）もこの方向で開発されています。 GoogleとのIETFは現在、現在のネットワークアーキテクチャを最大限に活用するために、それを破壊することなく最善を尽くしています。 そして、これを行うことができます...まあ、はい、TCP接続を可能な限り効率的に使用し、 多重化 、パケット損失からの回復などを通じて帯域幅を可能な限り密に使用します



したがって、Webサーバーおよびアプリケーションでの永続的な接続の使用を必ず確認してください。

TLS

もともとSSLとしてNetscape Communicationsの腸で始まったTLSがなければ、現代の世界にはどこにもありません。 そして、彼らは言うが、このプロトコルの最後の 「穴」は締め切りよりもはるかに早く多くの灰色に変わりました-実際には代替手段はありません。
しかし、何らかの理由で誰もがTLSが「後味」を悪化させることを覚えているわけではありません-TCPを介した1 RTT接続に加えて1-2 RTTを追加します。 nginxでは、デフォルトのTLSセッションキャッシュはデフォルトでオフになっています-これにより、余分なRTTが追加されます。



したがって、TLSセッションが必ずキャッシュされることを確認してください。そのため、別の1 RTTを保存します（残念ながら、セキュリティ料金として1つのRTTが残ります）。

おそらくバックエンドについてです。 さらに難しくなりますが、より面白くなります。

ネットワーク。 距離とネットワーク帯域幅

多くの場合、50Mbit / s、100Mbit / s、4Gでさらに多くの音が聞こえます...しかし、典型的なWebアプリケーションでは、帯域幅はそれほど重要ではない（ファイルがダウンロードされない限り）ことはランタンシーよりもはるかに重要であるという理解はほとんどありませんに。 多くの小さなリクエストが異なる接続で行われ、TCPウィンドウにスイングする時間がありません。
そしてもちろん、クライアントがWebサーバーから遠ざかるほど長くなります。 しかし、そうでなければ不可能または困難であることが起こります。 それが彼らが思いついた理由です：

1. CDN
2. 動的プロキシ（CDNまたはその逆）。 たとえば、nginxがリージョンにインストールされると、Webサーバーへの永続的な接続が開かれ、sslが終了します。 分かりますか？ つまり、クライアントとWebプロキシ間の接続が数回加速され（ハンドシェイクが開始されます）、加熱されたTCP接続が使用されます。

他にできること... TCPの初期輻輳ウィンドウを増やします-はい、これはしばしば助けになります。 Webページは、確認なしで1セットのパッケージで提供されます。 試してみてください。



ブラウザーデバッガーをオンにして、Webページの読み込み時間を確認し、待機時間とその削減方法を検討します。

スループット

TCP接続ウィンドウは最初にオーバークロックする必要があることに注意してください。 Webページが1秒未満でロードされる場合、ウィンドウを拡大する時間がありません。 世界の平均ネットワーク帯域幅は3メガビット/秒よりわずかに高いです。 結論-確立された1つの接続を通じて可能な限り送信し、「ウォームアップ」します。



単一のTCP接続内でのHTTPリソースの多重化は、ここで確かに役立ちます。要求と応答の両方で混合されたいくつかのリソースを転送します。 そして、この技術でさえ標準に含まれていましたが、過小評価されていたため、うまくいきませんでした （クロムでは、ごく最近になって削除されました）。 したがって、ここでは、まだspdyを試す、HTTP 2.0を待つ、またはパイプラインを使用できます。ただし、ブラウザからではなく、アプリケーションから直接実行できます。

ドメインシャーディング

しかし、非常に人気のあるドメインシャーディングテクニックについてはどうでしょうか。ブラウザ/アプリケーションがドメインごとに6以上の接続の制限を克服し、架空のドメインへの別の6以上の接続を開くとき：img1.mysite.ru、img2.mysite.ru ...？ ここが楽しいのは HTTP / 1.1の観点から-これはあなたを加速する可能性が高く、HTTP / 2.0の観点から-これはアンチパターンです TCP接続でHTTPトラフィックを多重化すると、スループットが向上します。
したがって、今のところ-ドメインをシャッフルし、HTTP / 2.0がこれを行わなくなるのを待っています。 もちろん、Webアプリケーション専用に測定し、十分な情報に基づいて選択することをお勧めします。

フロントエンド

Webページのレンダリング速度、画像とJavaScriptのサイズ、リソースのロード順序などのよく知られたものについて -書くのは面白くない。 テーマはbeatられ殺されます。 一言で言えば不正確-Webブラウザーの側でリソースをキャッシュしますが、...頭で。 10MBのjsファイルをキャッシュし、各Webページのブラウザ内で解析します-それが何をもたらすかを理解しています。 ブラウザデバッガをオンにし、コーヒーを注いで、一日の終わりまでに-傾向は明らかです。 計画の概要を説明し、実行します。 シンプルで透明。
はるかに鋭い落とし穴は、比較的新しく急成長しているWebブラウジング機能の背後に潜む可能性があります。 それらについてお話しします。

1. XMLHttpRequest
2. 長いポーリング
3. サーバー送信イベント
4. Webソケット

ブラウザ-オペレーティングシステムのような

当初、ブラウザはHTMLマークアップを表示するためのクライアントアプリケーションとして認識されていました。 しかし、毎年それは銀河系技術のコントロールセンターになりました。その結果、HTTPサーバーとその背後のWebアプリケーションは、ブラウザー内の補助コンポーネントとしてのみ認識されるようになりました。 興味深い技術的変化が強調されています。
さらに、ブラウザに組み込まれたWebRTC 「テレビスタジオ」の出現と、ブラウザのネットワークと外界とのやり取りの手段により、パフォーマンスの問題はサーバーインフラストラクチャからブラウザにスムーズに移行しました。 この内部キッチンがクライアントで遅くなる場合-Webサーバー上のphpを覚えたり、データベースに参加したりする人はいません。

この不透明なモノリスを部品について分析します。

XMLHttpRequest

これはよく知られているAJAX-ブラウザがHTTP経由で外部リソースにアクセスする機能です。 CORSの出現により、完全な「カオス」が始まりました。 ここで、ブレーキの原因を特定するには、すべてのリソースを登り、どこでもログを調べる必要があります。
真剣に、この技術は間違いなくブラウザーの機能を爆破し、動的に情報をレンダリングするための強力なプラットフォームに変えました。 それについて書くことには意味がありません、トピックは多くの人に知られています。 ただし、制限について説明します。

1. 繰り返しますが、複数の「チャネル」の多重化の欠如により、TCP接続帯域幅の使用が非効率的かつ不完全になります。
2. ストリーミングの適切なサポートがありません（接続を開いてハングします、お待ちください）、つまり サーバーを引っ張り、彼が答えたものを見ることが残っています

ただし、この技術は非常に人気があり、速度監視の観点から透過的にすることは難しくありません。

長いポーリング

ウェブチャットの作り方は？ はい、どういうわけか変更に関する情報をサーバーからブラウザーに送信する必要があります。 HTTP経由で直接-できません、できません。 のみ：要求と応答。 人々が決定したのは額でした：リクエストをして、答えを待ってください、秒、30秒、分。 何かが来たら、返して切断してください。

はい、多くのアンチパターン、松葉杖-しかし、この技術は非常に広く普及しており、常に機能しています。 しかし、なぜなら あなたは速度に責任があります-このアプローチでのサーバーの負荷は非常に高く、Webプロジェクトのメイントラフィックからの負荷と比較できます。 また、サーバーからブラウザへの更新が頻繁に配信される場合、主な負荷は何度も超える可能性があります！
どうする？

サーバー送信イベント

これにより、WebサーバーへのTCP接続が開かれ、閉じられず、サーバーは異なる情報をUTF-8に書き込みます。 確かに、予備のBase64なしではバイナリデータを最適に送信することはできません（サイズが33％増加します）が、一方向の制御チャネルとしては優れたソリューションです。 IEで真-サポートされていません（どこでも機能する上記の段落を参照）。




テクノロジーの利点は次のとおりです。

1. とてもシンプル
2. メッセージを受信した後、サーバーへの接続を再度開く必要はありません

Webソケット

システム管理者にとって、これは獣ではなく、夜の死体です。 HTTP 1.1アップグレードを通じて「巧妙な」方法で、ブラウザはHTTP接続の「タイプ」を変更し、開いたままにします。




次に、OBE（！）の接続を介して、メッセージ（フレーム）にフレーム化されたデータの転送を開始できます。 メッセージには情報が含まれるだけでなく、次のものを含む制御メッセージも含まれます。 「PING」、「PONG」と入力します。 第一印象-自転車が再び発明され、再びTCPに基づいたTCPが発明されました。
開発者の観点から-もちろんこれは便利ですが、ブラウザとサーバー上のWebアプリケーションの間に二重チャネルが表示されます。 ストリーミングが必要ですか、メッセージが必要ですか。 しかし：

1. HTMLキャッシュはサポートされていないため バイナリフレーミングプロトコルを使用する
2. 圧縮はサポートされていません。自分で実装する必要があります
3. TLSなしで作業する場合のひどいグリッチと遅延-古いプロキシサーバーが原因
4. 多重化なし。その結果、各接続の各帯域幅が非効率的に使用されます。
5. サーバーには、ブラウザからの直接のTCP接続が多数あり、「データベースにとって厄介な」ことをしています

Webソケットのパフォーマンスを追跡する方法は？ 非常に良い質問です。特におやつに残しました。 クライアント側（WireSharkパケットスニッファー、サーバー側、TLSを有効化）では、nginxのモジュールにパッチを当てることで問題を解決しますが、より簡単な解決策があるようです。

主なことは、Webソケットが内部からどのように配置されているかを理解することです。これは既にわかっており、速度制御が提供されます。
XMLHttpRequest、Long Polling、Server-Sent Events、またはWeb Socketsのどれが良いでしょうか？ 成功は、これらの技術の適切な組み合わせにあります。 たとえば、WebSocketsを介してアプリケーションを管理し、AJAXを介した組み込みキャッシュを使用してリソースをロードできます。

今何をしますか？

設定ポイントを測定して対応する方法を学びます。 Webアプリケーションのログを処理し、それらの遅いクエリを処理します。 ナビゲーションタイミングAPIのおかげで、クライアント側の速度も測定できるようになりました。ブラウザでパフォーマンスデータを収集し、JavaScript経由でクラウドに送信し、ピンバで集計し、逸脱に対応します。 非常に便利なAPIです。必ず使用してください。



その結果、 nagiosなどの監視システムに囲まれた状態になり、Webシステムの速度ですべてが正常であることを示す12個または2個の自動テストが行​​われます。 そして、肯定的な場合-チームが組み立てられ、決定が下されます。 ケースは、たとえば次のようなものです。

• データベースのクエリが遅い。 解決策は、クエリの最適化、緊急時の非正規化です。
• アプリケーションコードの実行が遅い。 解決策は、アルゴリズムの最適化、キャッシュです。
• ネットワークを介したページ本文の送信が遅い。 解決策（コストの増加順）-tcp initial cwndを増やし、動的プロキシをクライアントの隣に置き、サーバーをより近くに転送します
• クライアントへの静的リソースの戻りが遅い。 ソリューションはCDNです。
• ブラウザでサーバーへの保留中の接続をロックします。 解決策はドメインシャーディングです。
• ロングポーリングは、顧客がヒットするよりもサーバーに大きな圧力をかけます。 ソリューションは、サーバー送信イベント、Webソケットです。
• 遅い、Webソケットは不安定です。 解決策は、それらのTLS（wss）です。

など

まとめ

最新のWebアプリケーションの主要コンポーネントを調べました。 HTTP 2.0の傾向について理解し、Webアプリケーションの応答速度を可能な限り0.3秒に抑えるために理解して測定することが重要なコントロールポイントを学びました。 彼らは、ブラウザで使用されている最新のネットワーク技術の本質を見て、その利点とボトルネックを特定しました。

ネットワークの動作、速度、遅延、帯域幅を理解することが重要であることを理解しました。 そして、その帯域幅は常に重要というわけではありません。

Webサーバーとデータベースを「拡張」するだけでは不十分であることが明らかになりました。 ブラウザーで使用されるネットワークテクノロジーの概要を理解し、内部から把握して効果的に測定する必要があります。したがって、TCPトラフィックスニファーが右手になり、サーバーログの主要なパフォーマンスインジケーターの監視が左足になります。

さまざまな方法で「0.3秒」でクライアント要求を処理する問題を解決することができます。 主なことは、メトリックを決定し、自動的にそれらを収集し、それらを超えた場合に行動することです-各特定のケースのルートを掘ります。 当社の製品では、静的および動的サイトテクノロジーを組み合わせた包括的なキャッシングテクノロジーのおかげで、可能な限り低いレイテンシを確保するという問題を解決しました。

最後に、5月23日に間もなく開催される技術会議にご招待します。 Webプロジェクトの生産性を確保するという困難なタスクでの幸運と成功！