ウェブサイトの最適化。 診断と治療

イワン・ミキーエフ（AGIMA）

今日は、レポートの名前が明確になるように、最適化についてお話します。 一般的に、サイトを最適化する必要がありましたか？ 必要でした。 理解できないコードがどのように私たちにやってくるのか、たとえば、以前の請負業者から、またはその後再考しなければならないあなた自身のコードから、この道で多くの興味深いことが起こります。









ある種の野生のハードコアのために来た場合、残念ながら、あなたはこのレポートでそれを見ることができません。 今日お話しすることは、一般的に、Rocket Scienceはありません。複雑なことは何もありません。これらは、たとえば、高負荷で共有ホスティングを使用している場合、共有ホスティングでも入手できるツールです。 ツール、会社で行った最適化の例、スケーリングについて少し触れます。 これも最適化によるものですが、少し異なるコンテキストで行われます。







開発の歴史の道のりで私が最初に作った悲しい結論は、銀の弾丸は一般にどこにも存在しないということです。 つまり 最適化への道のりで遭遇する頭痛からすべての人を救う普遍的な解決策、普遍的なアプローチ、またはツールはありません。 したがって、ここにそのような結論があります-特効薬はありません。







また、経験から、昨日更新の日があり、昨日あなたのサイトがクラッシュした場合、特別な科学もここにないことに気付きました-それは更新中です。 何してるの？ ロールバックして、何が起こったのか、リリースで何が悪かったのかを把握し始めます。 これをすぐに理解することは重要です。







多かれ少なかれ現実に近い状況について話しましょう。 たとえば、Webサイトの負荷が増大しています。 おそらく均等に成長しますが、ほとんどの場合、不均等に成長し、ピークによって成長します。 そして、これらのピーク時には、あなたのサイトは非常に悪くなっています。 ページのレンダリングが無限に始まり、コンテンツの代わりに白い画面が表示され、500番ではなく500番のさまざまなランダムエラーが発生し、サーバーから接続が切断されることがよくあります。または、一般に、ページが半分読み込まれ、半分の画像が読み込まれません。 、一般的に、何らかの肉が起こっています。 これらのすべての症状は、ポータルまたはサイトの最適化を検討し、すでに改善に向けたいくつかの手順を開始する必要があることを示しています。







レポートを構造化するために、アプリケーションの典型的なコンポーネントを考慮します-それは何で構成されていますか？ 通常、どの言語でも、ユーザーインターフェイスが直接配置されているフロントエンドがあります。 サイトの場合、これはブラウザであり、アプリケーションの場合、ある種のインターフェースです。 アプリケーションが回転しているアプリケーションがあり、すべてのビジネスロジックが回転しています。 そして、データ層があります-それはDBMSである可能性があります、それは神の禁じられたXMLである可能性があります、それはアプリケーションでどんな形であれあなたに来るべきデータです。 そして、この構造を持って、問題に戻ります-私たちのサイトは愚かで、長い間ロードしており、いくつかの問題があります。 どこから始めますか？ この問題にアプローチする方法、私たちは何をすべきですか？







最初に頼むのは、フロントエンドを確認することです。これは、複数のオプションを一度にドロップして、どの方向に進むべきかを判断するのに役立ちます。







この段階での主な問題は、正確にサイトがスローダウンする理由に関連する問題です。 これは、ページの読み込みが不適切に長い、つまり スクリプトは可能な限り迅速に機能しましたが、ブラウザーでクライアントにコンテンツを配信するには非常に長い時間がかかることを理解しています。 CSSの実行がブロックされています。 これは、たとえば、ユーザーに最初に白い画面が表示され、それから何らかの形で彼にとって美しいものに変わった場合、これは良い状況ではないという事実です...コンテンツの部分的な読み込み、つまり 写真が非現実的に長く読み込まれている、またはモデルが非常に長い時間描画されている-これもそれほど状況ではありません。 すべてのJavaスクリプトのリストで80番目に接続されている何らかのスクリプトがあり、正常に機能しないことがわかっている場合、JSスクリプトの実行の遅延は、ここでも何かを最適化する必要があります。







診断用には、おそらくブラウザではなく、すべてのブラウザにあるかなり単純なツールがあります。



最初に頼むのはFirebugです。 誰もがそれを使用する方法を知っています-彼らはF12をクリックしました、そして最も古いものでさえ、それは間違いなくそこにあります。 彼らはそれをFirebugに貼り付け、そこにどんなリクエストがあったか、コンテンツがロードされたときに何ページが返されたか、そしてある種のスクリプトが実行されていたときに調べました。 通常は無料で、統計を見るだけで5分かかりました。まあ、F12キーに到達するのに数分かかりました。 それだけです、あなたはすべての統計を持っています、あなたはすでにどの方向に進むべきかの何らかの種類の理解を持っています。



非常に興味深いツールがあります-YSlow。 彼は、いくつかのメトリックに加えて、修正する必要があるものを言葉で伝えることもできます。 このツールは私にとって発見です。



また、Google PageSpeedもあります。これは、最前線で何かを変更する必要があるという事実に基づいて、サイトのランキングを上げる方法も示します。 ここで、ところで、フロントはブラウザとしてのクライアントの観点から考えられます。



したがって、彼らはこれらのツールを貼り付け、壊れたものを見て、私たちはすでに何かを修正し始めていました。







これらのメトリックを見るとき、何を探すべきですか？



最初の重要な、ほとんどのコンテンツサイトはこれに罪を犯します-これがDOMのレンダリング速度です。 DOMに多くの要素（1万を超える要素）が含まれているサイトがあります。これは、これをレンダリングするために既に問題になりつつあります。スクロールサイトが鈍くなると、電話で開くと、さらに大きな問題になります。 そのため、一般的にレンダリングがどれだけ困難かを見る価値があります。



2番目は、外部JSとCSSの存在です。 一般に、これは別のトピックです。サーバー上にないある種のJSがある場合、それが要求され、時には外部ライブラリがあるために最終的にどのサイズになるかわからないため、そして、それらはすべて複雑です。 そしてもちろん、これらのスクリプトの読み込みはブロックを開始します。 1つのスクリプトがロードされるまで待機し、その後、別のスクリプトのロードを開始します。 CSSでも同じこと、つまり ここでは、そのようなスクリプトを正しく選択する必要があります。おそらく、このJSが利用できるサービスの可用性だけでなく、それも重要です。



たとえば、かなり有名なフィットネスクラブのサイトを展開したときに、このようなケースがありました。 接続していくつかの操作を行う特定の外部スクリプトがありました。 開発者は開発しましたが、すべてがクールで、ブラウザにキャッシュされていることだけを考慮していませんでした。製品に組み込むと、このスクリプトの重量は0.5メートルになりました。 ディスク間の転送の一部としての500 Kbとは何ですか？ これらはそれほど大きな数字ではありませんが、ロードを開始するとき、プリロードがロードする秒数のときにあまりクールではありません。 さらに、開発者によってキャッシュされたグラフィカルコンテンツがまだ多くありましたが、キャッシュを要求するようには見えませんでした。 一般に、最終的にはFirebugを見ることが問題になる可能性があることに気づくまで、多くの研究が行われました。それがすべてです。



さて、サーバーへの接続を確立する時間。 ここではすべてがおもしろい。なぜならあなたの前線が本当につまらないのか、それとも何らかの弱いインターネットチャネルがあるのか​​を理解することが重要だからだ。 このような問題も発生します。ここでは、コードを掘るのではなく、ネットワークプロバイダーに対処する必要があります。







適用できるフロント最適化の方法は何ですか？



縮小、結合、圧縮-これらはすべて、ダウンロード時のファイルの重量と数という2つの要因にのみ影響します。 10個のJavascriptをロードし、そのうちのいくつかが外部サービスからのものである場合、これはフロントエンドにあまり影響しません。ブラウザーは、私の意見では、5つの同時接続（バージョンによって異なる）をサポートでき、他のすべてがブロックされるためです もちろん、同時に出荷する場合。 ある時点で組み合わせると、これを回避できます。10個のファイルのいずれかがあります。 そして当然、30 Kbに1つは1 Kbに30よりも高速にロードされます。 これを理解する必要があります。



しかし、ここに縮小（特にCSS）に関する次のポイントがあります。 デバッグの瞬間がある場合、それらの一部は製品の開発パネルを開き、数値の変更を開始します。これはすべて変更されており、まだそこにある行を示しています。 したがって、圧縮ファイルの場合、これらのミニファイヤにソースマッパーがない場合を除いて、行「1」が表示されます。 しかし、それでも彼らにとってはそれほど簡単ではありません。サワーマッパーの中には、あなたにいくつかのキーしか持っていないものもあるため、メイン要素がどこから始まるかを示しています。 そして、コードの正確な場所は非常に難しい場合があります。 ここでも、非常に有能にアプローチを適用する必要があります。これは、デバッグの際にあなたにトリックをかける可能性があるためです。



圧縮 メディアコンテンツは正確に圧縮する必要があり、一部のFull HD画像は100 x 100ピクセルのコンテナーにロードしないため、ここではおそらくすべてが透明です。 今でも写真が小さいように見える場合があり、そこでフルHDを駆動し、クライアントは「なぜそんなに長いの？」と言います。 この点も考慮に入れる必要があります。



最適化ツールの2番目のグループは、JSコードのリファクタリングです。これは、そのように書かれているために愚かであることが多いためです。 特に、完全に理解していないフレームワークを使用しており、DOMが数千の要素で構成されており、何らかのjQueryイベントなどがある場合 要するに、すべてが実際には非常に高速に動作しません。



まあ、DOMの最適化も重要です。 iPad 1または2が記憶されている場合、たとえば、woman.ruなどのニュースポータルなど、あらゆる種類のコンテンツサイトを読み込むと問題が発生します。 彼らは歴史的にDOMが非常に複雑である、つまり たくさんの要素があり、iPadだけでは消化できませんでした。 あなたはサイトを開いて、それをレンダリングし、レンダリングし、レンダリングしたように見えましたが、特別なことは何もなかったので、このトピックで非常に最適化する必要がありました。 おそらく非常に長い時間がかかりました。



これらの点はすべて、単純にWebサイトのパフォーマンスを高速化することにつながります。







また、無料のアドバイスは、クライアントとは関係がなくなりましたが、プロキシまたはnginxサーバーの前面に向けられたものです。nginxを通じてstaticを指定する必要があります。 これまで、静的がnignxを通過し、ディスクにあまり影響を与えないようなケースに遭遇しました。したがって、サイトが愚かで、他のすべてが正常であると思う場合は、静的を確認します-nginxを介してそれを取得します与えられたかどうか







さらに興味深い部分に移りましょう。これらはアプリケーションとDBです。 エラーの大部分が実際に発生し、最適化のテストの場を提供する部分。







あなたのページがゆっくりと形成されている、スクリプトがひどく実行されている、htmlが生成されている、500番目のエラーが頻繁に発生している、など... 500番目はすでに鐘です。 監視システムを介してサイトのダウンタイムを監視している場合、アラームを鳴らす必要がない場合は、ここですべてが問題ないかどうかを検討する価値があります。 これがいくつかの単一のケースである場合、一連のこのようなケースである場合は、考えて、見て、分解することができます。ここで、このタスクに包括的な方法でアプローチする必要があります。







アプリケーションまたはDBの速度が低下した場合のオプションは何ですか？ 実際、次の3つの重要なブロックがあります。

• サーバーがリソースを使い果たしました。
• プログラマーは非常に高品質ではないコードを作成しました。
• または、データベースで何か問題が発生しています。

一般的に、これをすべて理解する方法は？







最初に頭に浮かぶのは、プロファイラーをそこにインストールするのではなく、奇妙なものを発明するのではなく、単に端末に入って通常のOSツールを使用することです。



サーバーに残っているメモリの量を理解するのに役立つtopコマンドがあります。 strace、lsofなどがあります。 これらのコマンドはすべてLinux OSにあり、Windowsでも同様のコマンドがあります。 そのようなことは何もせず、すべて手元にあります。サーバーの現在のステータスを見るだけです。 そして、心配することはまったくありません。



ある小売業者のケースがありました。 それらはディレクトリのようなものを持っています、たぶん、あなたは知っています、彼らはpdfにポンプでくまれます。 そして、彼らが投稿した日に、何らかの理由で、多くの人々がそれらをダウンロードし始めるのは興味深いことです。 どのような目的で使用するかはわかりませんが、なんらかの理由で実際に2,000人がこのポータルにアクセスして、ディレクトリのダウンロードを開始しています。 そして、私たちのサイトは少し到着しました。 彼らは理解し始めました。 システム管理者はラップトップをスタックし、すべてのファイルがaccess_logsのapacheを通じて提供されていることに気付きました。 しかし、もちろん、Apache経由でPDFファイルを提供することはあまり良くありません。 configをnginxに切り替えただけです（繰り返しますが、アドバイスを覚えていますか？-nginxを介した統計）、すべてが飛んでいます。 つまり ここに明確な例があります-5分かけてラップトップを固定し、ディスクで何が起こっているのか、access_logを見て、それだけです。 そして、すべてがすぐに明らかになり、修正されました。



たとえそれがさらに涼しくても-監視システムがあれば、OSに行く必要さえなく、それらすべてを理解できます。 つまり サーバーがどこで、どこで小さな危機に陥るかを理解するためのさまざまなメトリックがあります。







2番目のポイントはスローログです。 スローログはほぼどこにでもあり、この要求またはその要求が発生した場所、またはスクリプトが異常に長い時間実行された場所と時間を判断するのに役立ちます。 遅いログ、おそらく問題、あるいは問題ではないが、議論する理由にすぎないという主なトピック-これは遅いリクエストを決定する時です。 ここのすべては実際にはさらに簡単です。 あなたはシステムの所有者であり、スクリプト実行リクエストのどの時間が最適であるか、またはあなたにとって受け入れられるかを知っています。 スローログを設定して、すべての重要なリクエストが書き込まれ、すべての重要でないリクエストが書き込まれないようにします。 2つのリクエストが3秒以上実行された場合にカウントしないようにするには、どの時間が重要であるかを理解することが重要です。 統計、計算、レポートなどが存在するため、リクエストを完了するのに5秒かかるのは通常のことです。







別のヒント-開発の開始時にスローログを含めることをお勧めします。 これにより、予期しない負荷のピークとその後の「何が起こったのか」などの結果報告からあなたを救います。 同じ更新で、製品にロールアウトし、負荷がサーバー上で非常に不均一にジャンプし始めると、すぐにロールバックして状態を戻す必要があるためです。 また、スローログが有効になっていない場合、統計やメトリックを収集するのは非常に困難です。 オンにした場合は、メトリックを確認してからすべてを決定し、何らかの負荷テストを行うことができます。 それだけです。



また、さまざまなログがあります-これはerror_logとaccess_logです。 私たちが自由に使用できるすべてのサーバーツールは、追加のツールを使用せずに使用できます。 これは、OSボックスにあるものに加えて、監視です。 ただし、モニタリングはすでに設定されている必要があります。







あなたのアプリケーションをより速く理解するための次のステップは、もしそれがあなたのものでなければ、プロファイラーです。 プロファイラーはほとんどすべての言語に対応していますが、すべての言語に対応しているようです。 そして、各自尊心のプロファイラーには、原則として、どのプロファイラーでも同じである特定の利点があります。 これは使いやすさ、つまり どの時点で開始できるか、どこで終了する必要があるか、設定に書き込むか、何を書き込むべきか、どのような動作特性などを決定するだけです。 出力では、プロファイリング中に実行されたすべての関数のコールスタックを取得します。 どの関数がどれだけ実行されたかがわかります。この関数がどれだけ実行されたか、ネストされた関数がいくつ実行されたか、それが消費するメモリ量がわかります。 また、プロファイラーログを使用するとコールグラフを作成できるため、負荷が高いアクション（この場合は実行時間がn秒より長い）のルートをトレースできます。







たとえば、Xhprofがあります。 PHPで開発しており、Xhprofがあります。 これは彼がどのように見えるかです。 多くのプロファイラーが同様のインターフェースを持っているように思えます-コールスタックのある特定のテーブルがあり、いくつかの複雑なクエリがどこで始まり、どこで終わったかを示す特定のグラフがあります。



Visual Studioプロファイラーもありますが、これとは異なり、多くのプロファイラーは多くの言語で簡単にグーグル検索されます。



さらに、何をする必要があるかをよりよく理解するために、小さな例を検討することを提案します。 症状から始めましょう。







サイトが非常に遅いことに突然気付きました。 この場合、スクリプトの実行時間が長いのはサーバー上です。 すべてのルールが前面にあることに気付きましたが、スクリプトの作成にはいくつかの問題があります。 必要なのは、プロファイラーまたはスローログです-好きなように、誰が何を持っているか、誰が何を設定できるかです。



そして、そのような小さなことはEXPLAINチームです。 将来、あなたはその理由を理解するでしょう。







プロファイラーを使い続けると、1秒で14個のMySQL_query呼び出しが行われることがわかります。 あまり良い指標ではありません。







少し上をたどると、getNewUserNotificationCNTと呼ばれる関数が640ミリ秒であり、ほとんどの場合、この640のうち、リクエストを実行することがわかります。 つまり プロファイラがここで機能していることを簡単に想定して理解できます。この機能がボトルネックです。 必要なのは、この関数に入って、どのようなリクエストが実行されるかを確認することだけです。







リクエストは非常に簡単であることがわかります-これは、新しい未読の通知の数の選択です。 , , , , , , EXPLAIN SELECT':







, SELECT, , . , . , , , - 10 , . , COUNT (*) – . , - . EXPLAIN, , .







. ALTER TABLE, INDEX USER_ID . ? . , 1 . .



, EXPLAIN, , , , - .



. EXPLAIN. EXPLAIN -, , , , EXPLAIN , , . , , , , . , .



- join' - , EXPLAIN , – where – . , , , , .







1 300 . , . , 2,5 , – 700 . つまり , .



? :







, – . , - , , , , , , , join' - . - , get list, get list' - get list . .



– , .. - , while - , , . , .



( ) – . , - , , , . , .







それをどうしますか？ , , , - , code review .







, , . , , – . . - , real time , cron, , - , , - , .







. , , , . – , , , . , excel, , , . , .. , : « , 5 », . .







, , , , , , , , , , , .







, – . つまり , , - .



:

1. – , , ;
2. , . – , .. - , , , , .. , , .

, , . - , 10 . - , , 100 1 . , 100 150. .







, , , , . - – . , , – , , .



, .. , - , , , .



, .. - , , , – .



– . , , , .



. , , , , , - , .

連絡先

» miheev@agima.ru

» Facebook

— HighLoad++ Junior . HighLoad++ Junior — HighLoad++ 2016 — HighLoad++ , 7 8 .



— Junior — . highload (, , ). HighLoad - — , nginx :)



- HighLoad.Guide-これは、特別に選択された文字、記事、資料、ビデオのチェーンです。私たちの教科書にはすでに30以上のユニークな資料があります。接続してください！