2012-03-23 31 views
0

私はWebアプリケーションで作業しています。私はポーリング手法を使用して、更新が必要かどうかを確認しています。これらのポーリング要求は、1秒または2秒ごとに発生します。更新が必要でない場合(空の応答が返された場合)、コンテンツ自体のサイズである約10KBの場合、応答のサイズは240バイトです。私の問題は、毎秒およそ240Bを返すので、境界をもう少し押してこの応答を最適化する方法があるのでしょうか?レスポンスのサイズを小さくする

レスポンスの内容を確認したところ、50バイトは私にとって不可欠なものでした(セッションIDとステータスコード)。ただし、ヘッダーには、接続タイプ、タイムアウト、コンテンツタイプなどの情報があります。これらの設定は、このタイプのリクエストごとに同じになります(コンテンツタイプとして「text/html; carset = utf-8」が必要です)。だから、私はこれらの設定をクライアント側で想定し、サーバーがこれらのヘッダー情報を送信しないようにすることはできますか?

私はサーバーサイドでdjangoを使用しています。途中でajaxリクエストを送信するためにjQueryを使用しています。また、あらゆるタイプのプッシュ技術は今のところ問題視されていません。

答えて

1

この種の問題の解決策の1つは、「長いポーリング」です。ポーリングクライアントは要求を送信し、Webサーバーは更新があるかどうかを確認します。存在しない場合、Webサーバーは1〜2秒間スリープした後、応答を送信せずにループで再度チェックします。このループは更新を確認するとすぐに、応答を送信します。クライアントのWebブラウザには、サーバが輻輳していて応答に時間がかかるように見えますが、実際に関連するデータは速やかに送信され、「データなし」の応答は単にスキップされます。

ループにタイムアウトを追加することをお勧めします。たとえば、30秒または60秒です。その後、Webサーバーはいつものように「データなし」と応答します。わずか30秒のサイクルでも、空の応答負荷を15〜30倍に減らすことができます。

注意:私はこの種の実装について読んだことがありますが、私はそれを自分で試していません。このような非標準的な方法でもクライアント側で問題が発生しないように、さまざまなWebブラウザとの互換性をテストする必要があります。

+0

ロングポーリングを確認しました。それは妥当と思われる。ただし、常にスリープ状態になるとサーバー側で過負荷が発生することはありません。私は、サーバーのパフォーマンスの問題について多くの知識を持っていません。 – Hgeg

+1

time.sleep(2)のようなスリープメカニズムを使用していると仮定すると、それは通常のポーリングと比べるとパフォーマンスが低下しません。これは実際にCPU時間を節約するはずですが、おそらくホストマシン上でより多くのメモリを消費します。というのも、各要求スレッドはずっと長い間メモリ内にあるからです。あなたのアプリケーションに合っているかどうかは、あなたの状況の詳細やあなたのユーザー数に依存します。しかし、それは間違いなく帯域幅を節約します。 –

2

あなたが思っているほどではありませんが、それほど多くはありません。一時間に1秒ごとにポーリングした場合、864Kしか使用できませんでした。これは、標準化されていないキャッシュでは通常のWebページに必要なものよりも少なくなりました。あなたが1日中それをしたとしても、あなたは約20M話しています。たぶん、あなたがTwitterのような人なら、これについて心配する必要があるかもしれませんが、実際には問題があるためには、トラフィックの近くにどこにでもいることに疑いがあります。

しかし、もちろんリクエストのヘッダーをカスタマイズすることはできますが、これがクライアントに与える影響がテストすることになります。一部のヘッダーはおそらく削除される可能性がありますが、他のヘッダーはあなたを驚かせるかもしれませんし、技術的にはブラウザごとに異なる可能性があります。

関連する問題