22

私はインタビューで一度この質問をされました:

「サーバーが離れた場所にあるウェブサイトを所有しているとします。ある日、サイトがひどく遅いと言うユーザーからの電話やメールがあります。サイトが遅い理由をどのように特定しますか?また、自分でウェブサイトを確認すると、すべてのユーザーが(ブラウザを使用して)、サイトは問題なく動作します。」

私は(撃墜された)1つのことしか考えられませんでした:

  • サーバーログを確認して、着信トラフィックを分析します。たぶん、DoS攻撃または非常に高いトラフィック。インタビュアーは、サーバーには通常のトラフィックがあり、DoSがないと想定するように言った。

私はこの問題について考えたことがなかったので、ちょっと迷いました。サーバー/ウェブサイトの実行がどのように機能するかはほとんどわかりません。したがって、誰かがいくつかのアプローチを強調することができれば、それは素晴らしいことです。

グーグルをしていると、この関連性のある素晴らしい記事しか見つかりませんでした。その記事は今の私にはちょっと技術的すぎますが、私はゆっくりとそれを分解して理解しています。

4

9 に答える 9

17

自分でサイトをチェックするときに速度は問題ないと言ったので、これは(少なくともチェックしたページについては)サーバーに問題はなく、それらのページを適切な速度で提供できることを意味します。この時点で理解する必要があるのは、サイトが遅いと報告するユーザーとの違いです。それは多くの異なるものかもしれません:

  • ユーザーは低速のネットワーク接続(モバイルなど)を使用していますか?
  • ユーザーは、同じウェブホスティング業者でホストされている他のウェブサイトで同じ問題を経験しますか?その場合、これはネットワークの問題を示している可能性があります。通常、これはWebサーバーのリソースの問題を示している可能性もありますが、その場合、サイトの速度も低下します。
  • 上記のいずれも答えにつながらない場合は、サーバーへの接続とサーバー自体は正常であると見なすことができます。これは、問題がユーザーのデバイスにある必要があることを意味します。彼が使用しているブラウザ/OSを見つけて、問題を再現してみてください。それが失敗した場合は、問題を引き起こす可能性のあるウイルス対策ソフトウェアまたは同様のソフトウェアを使用しているかどうかを調べます。
于 2013-03-27T18:01:22.813 に答える
8

これは、Webページの速度を見つけるための優れたツールであり、速度が遅くなる原因を教えてくれます:https ://developers.google.com/speed/pagespeed/insights

于 2013-03-27T05:49:30.383 に答える
4

上記の回答に欠けている重要なことの1つは、Webパフォーマンスに不可欠なサーバーの場所です。

誰かがウェブページを開くのに時間がかかると言っているとき、それは高い待ち時間を意味します。サーバーの場所が原因で、待ち時間が長くなる可能性があります。あなたがWebページの所有者であるため、サーバーとクライアントが同じ場所に配置されていると仮定します。これにより、待ち時間が短くなります。

しかし、クライアントが国境を越えている場合、待ち時間は大幅に増加します。したがって、パフォーマンスが遅くなります。

もう1つの要因は、レイテンシー時間に大きく影響するキャッシングです。

フェイスブックを例にとると、世界中にサーバーがあり、待ち時間を短縮し(また、他のいくつかの利点も提供します)、巨大なキャッシュシステムを使用してホットデータ(トレンドトピック)をキャッシュしますが、コールドデータ(古いデータ)はハードディスクに保存されるため、古い写真や投稿を読み込むのに時間がかかります。したがって、ユーザーはコールドデータをロードしようとしたときに、これについて不満を言う可能性があります。

于 2016-04-13T05:29:11.417 に答える
2

私はこれらのいくつかの理由を考えることができます(最初の2つはすでに上で述べられています):

  1. クライアントの場所が原因でレイテンシが高い
  2. サーバーメモリを増やす必要があるかもしれません
  3. ページからのサービス呼び出しの数。
  4. 苦情の時点でサービスがダウンしている可能性がある場合は、ページの読み込みが妨げられる可能性があります。
  5. エクスペリエンスが悪い場合は、サーバーの負荷が高すぎる可能性があります。サーバーはリソースを増やす必要があるかもしれません(例えば、クラスターに別のサーバー/ Webサーバーを追加する)。
  6. その時点でサーバー上で実行されているバックグラウンドジョブがあったかどうかを確認します。

バッチジョブのログとスケジュールを確認して、その時点で何が実行されていたかを判断することが重要です。

この助けを願っています。

于 2017-02-02T20:20:55.293 に答える
1

通常、ユーザーは、サイトが遅いことを確認するための手段としてページの読み込み時間を取ります。しかし、何が最大の時間を費やしているのかを本当に知りたい場合は、f12を押してブラウザーデバッガーを開くことができます。ブラウザがChromeの場合は、ネットワークをクリックして、アプリケーションが発信している呼び出しと、最大の時間がかかっている呼び出しを確認してください。Firefoxを使用している場合は、firebugをインストールする必要があります。それがある場合は、もう一度f12を押して、[ネット]をクリックします。

于 2013-03-27T05:50:08.807 に答える
1

1つの理由は、ユーザーの役割があなたの役割と異なることである可能性があります。管理者権限(スーパーユーザーの役割など)を想定している可能性があり、コードはそのような役割のすべてを許可しているだけである可能性があります。つまり、許可されているかどうかを確認するための条件付きチェックはあまり行われません。場合によっては、ユーザーのすべての特権を取得して条件をチェックするのはかなり先のことです。コースは、承認の実装方法によって異なります。つまり、特定の役割ではページが非常に遅くなる可能性があります。したがって、ユーザーの役割を調べて、それが理由であるかどうかを確認する必要があります。

于 2014-04-27T17:26:27.520 に答える
1

明らかに、サイトに接続している人の接続に問題があるか、一時的な問題である可能性があり、サイトをチェックするまでにすべてがダンディでした。ログを確認するか、速度低下が発生したときに問題があったかどうかをホストに尋ねることができます。

于 2015-04-14T16:38:11.613 に答える
0

これは通常、メモリの問題であり、アプリケーションをホストしているWebサーバーのヒープサイズを増やすことで解決できます。アプリケーションがWeblogicServerで実行されている場合。ヒープサイズは、アプリケーションホームにある「setEnv」ファイルで増やすことができます。幸運を!マイケル・オレベ

于 2015-11-20T02:09:23.450 に答える
0

あなたの質問は非常に明確ですが、Webサイトの最適化は非常に広範なテーマです。

人気のあるWeb開発フレームワークの大部分は、何らかの理由で、プロセッサの効率が非常に低くなっています。

n層Webアプリケーションを開発する昔ながらの方法は、依然として非常に関連性があり、W3Cによると依然としてベストプラクティスであると考えられています。最も人気のあるWeb開発フレームワークのソースコード構造を読むのに少し時間がかかると、サーバーで必要以上のコードが実行されていることがわかります。

これは少し単純な答えのように思えるかもしれませんが、サーバーで実行するコードが少なく、クライアントで実行するコードが多いほど、サーバーの動作が速くなります。フレームワークコードを昔ながらの方法と対比することが、これを理解するための最良の方法である場合があります。これは、W3Cのベストプラクティスを表し、サーバーで最小量のコードを実行し、クライアントで最大量のコードを実行する、完全に機能するミニWebアプリケーションへのリンクです。http://developersfound.com/W3C_MVC_EX.zipこのコードベースはまた、MVCに準拠しています。

このコードベースには、MySQLデータベースダンプ、php、およびクライアント側のコードが付属しています。このコードの動作を確認するには、SQLダンプをMySQLインスタンスに復元し(SQLダンプはMySQL 8コミュニティから取得)、phpファイル(conn_include.php)にあるユーザーとスキーマのアクセス許可を追加する必要があります。スキーマに対する実行権限を持つようにユーザーを設定します。

このコードベースを最も人気のあるすべてのWebフレームワークと比較すると、これらのフレームワークがいかに非効率的であるかがわかります。MVCフレームワークであると主張する人気のあるPHPフレームワークは、実際にはMVCにまったく準拠していません。これは、PHPタグをHTMLタグ内に埋め込むか、またはその逆に依存しているためです(W3Cによると非常に悪い習慣と見なされています)。また、最も一般的なノードフレームワークは、サーバーで必要以上のコードを実行します。フレームワークがYii2などのAJAXダンプをサポートしていない限り、埋め込みタグは非同期呼び出しが正しく機能しないようにします。

MVCコンプライアンスで従うべき最も重要なルールの2つは、サーバー側のタグ(PHPタグなど)をHTMLタグに埋め込んだり、その逆を行ったりしないことです(SEOなどの非常に良い言い訳がない限り)。クライアントで実行できる場合はサーバーで。また、真のMVCは層の分離に基づいていますが、MVCフレームワークはコードの分離に基づいています。真のMVCコンプライアンスは、プロセッサー効率が非常に高いです。誤解しないでくださいMVCフレームワークは多くのことに非常に役立ちますが、何百万ものヒットを獲得するサイトを開発している場合、それらはまったく役に立たないか、少なくともクラウドの請求額が非常に高くなりますそれは本当にあなたの会社の利益に食い込むでしょう。

要約すると、フレームワークは、クライアントまたはサーバーで実行されるコードをあまり制御できず、非常に非効率的ですが、より少ないコードでプロトタイプをより迅速に稼働させることができます。

対照的に、昔ながらの方法では少し多くのエルボーグリースが必要ですが、サーバーで実行されるものとクライアントで実行されるものを完全に制御できます。

最適化のための追加のアドバイスとして、パススルークエリとトリガーの使用を避け、代わりにストアドプロシージャを選択してください。歴史的に保存されたプロシージャは、MVCがパラダイムとして存在していた時点では発明されていませんでしたが、階層間の関心の分離が確実に向上し、プロセッサの効率が大幅に向上しました。

このアドバイスがお役に立てば幸いです。

于 2019-06-02T23:02:23.903 に答える