AJAXを使用すると、サーバーのパフォーマンスが大幅に向上しますか?


10

明らかにAJAXはユーザーインターフェイスを改善しますが、これによりサーバーの負荷も減少しますか?ページ全体を毎回提供する必要がないため、そうだと思うかもしれませんが、他に考慮していない変数がある可能性があります。

回答:


14

それはあなたが何をしているか、そしてあなたがそれをどのようにしているかに依存します。

  • 全ページの読み込みをAJAXリクエストで置き換える場合(つまり、ユーザーが全ページの読み込みだったものをクリックしたときにのみAJAX呼び出しを行う場合)、(おそらく)処理が少なく戻り値が少ないため、AJAXはサーバーの負荷を減らします。データ。

  • 一方、数秒ごとにサーバーをポーリングする自動更新タイプのAJAXを追加すると、ユーザーによっては負荷増加する可能性があります(ユーザーがF5を押し続けて手動で更新すると、サーバーの負荷が増加しない可能性がありますが、ほとんどの人は一般的に何時間もそうしません)

  • もう1つのAJAX最適化は、スクロールするときに、より多くのデータのみをロードすることです。その場合、ユーザーが一番下までスクロールしないと、無駄な処理になります。

もちろん、実際の実装はどちらの方法でも結果を歪める可能性があります。これらは、適度に優れた実装を想定した典型的な結果です。


ここでの本当の問題は、AJAXのやり方に移行すると何が変わるのかということです。AJAXに移行するか、単に細かく分割するだけで、以前は無駄になっていた作業を排除できますか?(およびプロセスにオーバーヘッドを追加する)
SplinterReality '18 / 10/18

3

もちろん、サーバーの負荷を減らすのに役立ちます。このプレゼンテーション@ jsconf'09を見てください-Facebookがどのようにajaxを使用してそれを行ったかについては。

Ajaxは非同期です。サーバー通信-そして、あなたは無数の方法でそれを使うことができます。人々はシンプルなJSONをリアルタイムWebにロードするために、そしてその間のすべてにそれを使用します。

覚えておいてください-本当の課題は、クライアントとサーバーのバランスです。各当事者がシステムを最適化し、知覚される応答性と実際の速度の明らかな利点を得ることができるように、各当事者に仕事をさせるよう努めます。


3

あなたが考慮していない他の要因があります-ほとんどの場合、AJAXはサーバーの負荷を増加させます。一般的な非Ajaxシナリオでは、ユーザーは数秒または数分ごとに1つの大きなページをロードします。はい、その単一ページはサーバーにとってもう少し作業ですが、他の要求を回復して処理するために、要求の間に十分な時間があります。AJAX化されたシナリオでは、その単一ページのロードは数十の小さなヒットになり、常にサーバーをハンマーで叩いて応答を待ちます。

これは、1000カットによる死のようなものです。リクエスト自体はそれほど大きなものではありませんが、総重量はキラーです。特に、これらの小さなリクエストは、フルページリクエストと同じくらいのコストがかかると考え始めると、どちらの場合も、おそらくWebアプリケーションパイプライン全体を実行しており、データベースにアクセスして、貴重なHTTP接続に座っている間に回答を待っています。

以下は、ajaxがサーバーで醜い方法を実際に高速に実行する方法の例です。ウィジェット用の4つのスロットを備えた典型的な「エグゼクティブダッシュボード」を見てみましょう。CEOが右側の完全な販売レポート、真ん中のトップ10の稼ぎ手のリスト、右側の会社の株価レポートを気に入っているとしましょう。そして、単純なajaxリモート要求を介してこれを行うとしましょう。スタイルシート、画像、その他のアセットを考慮せずに、ページに対してサーバーに対して4回のHTTPラウンドトリップ(メインページ、各ダッシュボードレポート)が必要になりました。これらのそれぞれを実行するには、完全なWebスタックが必要です-データベースにアクセスし、Webフレームワークを使用してHTMLをレンダリングすることになりますよね?次に、1人のCEOに2000人のリモートユーザーを掛けます。

逆に、レポートをレンダリングするために、HTMLスケルトンとデータ(ページ内JSONに含まれる)を実行して返す単一のサーバー側ページを作成することもできます。単一のより大きな接続ですが、4つのリクエストを処理せず、4つのパイプラインをスピンアップしないため、合計でWebサーバーの負荷が少なくなります。


1
AJAXで必要な小さなリクエストの例を教えていただけますか。
11

1
確かに-このサイトで、誰かがすでに質問に回答したかどうかを知る方法に気づいたことはありませんか?これは小さなajaxリクエストを介して行われます。。。
ワイアットバーネット、

@WyattBarnett AJAXは必ずしもポーリングを意味するわけではありません。完全なページの読み込みを部分的なページの読み込みに置き換えるだけです。多くの場合、サーバーの負荷が増加する可能性がありますが、「ほとんどの場合」ではそうではないと思います。
Davy8 '27 / 09/27

えーと、まあ、その例は、他の方法よりも多くのサーバー要求を必要とするものではなく、AJAXで他の方法では実行できないものに似ているように思えます。私は彼が意味している場合、「より多くのパフォーマンスを正確に同じことをやったときに」OPは不明であったか、「AJAXのフルに活用したときに、よりパフォーマンスを」彼が意図した場合に想定
jhocking

1
ポーリング/ロングポーリングはAJAXのサブセットにすぎないことに注意してください(ここで説明したとおり)。これは「comet」とも呼ばれます。「真の」ポーリングのないプッシュまたはサーバーサイド(サーバー起動)AJAX を可能にするWebSocketは、この種の機能に必要なリソースの浪費を大幅に削減します。
アランH.

2

AJAXを使用して、サーバーが行う作業を置き換える場合は、サーバーのパフォーマンスが向上します。ただし、サーバーが引き続き同じように動作し、AJAXで発生していることがサーバーがすでに実行しているものの上にあるように設計した可能性があります。

これは主にUIに関するものです。クライアント側で他に何もするべきではないからです。基本的に、UIをサポートするためにサーバーが行っていたすべてのこと(たとえば、ユーザー入力に応じて異なるレイアウトでページを再読み込みするなど)は、代わりにJavaScriptを使用して行います。


0

HTMLレンダリングがアプリケーションサーバーのパフォーマンスプロファイルの大部分を占める場合、HTMLレンダリングをクライアントに移動すると、アプリケーションサーバーのパフォーマンスが向上します。

ただし、HTMLレンダリングがアプリケーションサーバーのパフォーマンスプロファイルのごく一部である場合、通常、リクエストの数が増えると、スタックを通過する回数が増え、クエリが増え、アプリケーションサーバー上のすべてのものが増え、パフォーマンスが低下します。

もちろん、あなたの特定のケースで知る唯一の方法は、それを試すことです。


1
AJAXを使用すると、AJAXを使用せずに同じことを行うよりも多くのリクエストが発生する例について考えるのに苦労しています。例を挙げていただけますか?
11

1
HTMLは常にクライアント側でレンダリングされます。
ジョナス

1
おそらく彼は間違ってスポークし、「レンダリング」ではなく「操作」を意味していました
jhocking

ビュー/テンプレートから始め、それを変数と組み合わせ、そこから生のHTMLをレンダリングします。
yfeldblum 2011

AJAXを使用すると、AJAXを使用せずに同じことを行うよりも多くのリクエストが発生します。メインレイアウトには「穴」がありますが、それらの穴がブラウザーに配信され、それらの穴はAJAXを使用して「埋められます」。Facebookなどを参照してください。
yfeldblum 2011

0

ソリューションを実装する最良の方法を検討する必要があります。単純な非動的フォームはajaxを必要とせず、追加すると実際にはパフォーマンスに悪影響を与える可能性があります。問題が悪いクエリである場合、世界中のすべてのajax最適化では、許容できるパフォーマンスの向上は得られません。

サーバーが過負荷の場合は、その理由を理解する必要があります。

大量のヒットが発生している場合、ajaxはその問題を解決しないため、より多くの容量が必要です。ajaxを追加すると、サーバーが処理する必要のあるリクエストの数が増えるだけです。

複雑なページがある場合は、サーバーの負荷を軽減するためにクライアント側で実行できることを確認する必要があります。ページが動的であるが、実際にはデータパッケージキャッシングが制限されている場合、クライアント側の調整ではより効果的です。

そして、時にはAjaxが役立ちます。動的データを伴う複雑なフォームがある場合、ajaxが勝利します。しかし、クエリが複雑で実行に時間がかかる場合でも、ajaxは問題を解決しません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.