20

最初に、私のバックグラウンドについて少し説明します。私はしばらくの間 (この時点で 10 年) プログラミングをしており、アイデアのコーディングに関してはかなり有能です。私はちょうど 1 年ほど前に Web アプリケーション プログラミングに取り組み始め、ありがたいことに nodeJS を発見しました。これにより、Web アプリの作成が従来のプログラミングのように感じられるようになりました。今、私はしばらくの間開発してきた node.js アプリを持っており、現在は Web 上で運用されています。私の主な混乱は、私が Web 開発の世界に非常に慣れていないという事実から生じており、アプリケーションの監視に関して何が重要で何が重要でないかを本当に知りません。

私は Joyent SmartMachine を使用していますが、それらが提供する分析オプションを見ると、少し圧倒されます。非常に多くの異なるオプションと構成があり、各分析が実際にどのような目的を果たしているのかわかりません。以下の質問については、Joyent の Cloud Analytics に固有のものであろうと、完全に一般的なものであろうと、回答をいただければ幸いです。


質問 1

現在、私の主な関心事は、アプリケーションを実行しているサーバーをアプリケーションがどのように利用しているかを把握することです。アプリケーションに適切な量のリソースが割り当てられているかどうかを知りたいです。受信するリクエストの数によってサーバーが過負荷になるか、それとも追加のリソースが必要か? その目的のために、NodeJS アプリで注目すべき重要な分析は何ですか? (違いが生じる場合は、MongoDB と Redis の両方を別のサーバーで使用します)


質問 2

実稼働中のサーバーを管理する際に、一般的に確認することが本当に重要な統計は他に何ですか? 私は、継続的に実行され、多くのクライアントと対話する Web アプリとは対照的に、特定のことを行うために一度実行されるプログラム (たとえば、画像を計算すると実行を終了するレイトレーサー) に慣れています。長年のサーバー管理者には明らかなことが、私のような初心者には明らかでないことがたくさんあると確信しています。


質問 3

具体的に NodeJS を扱う際に注意すべき点は何ですか? NodeJS とより標準的なサーバー システムのシングル スレッド イベント ループを処理するときに特に重要になる統計/分析は何ですか?

データベースが方程式にどのように関与するかについて他にも質問がありますが、今のところはこれで十分だと思います...

4

3 に答える 3

15

0.4 シリーズから現在の 0.8 シリーズまで、約 1 年間、node.js を本番環境で実行しています。Web アプリは、mongo、redis、および memcached を使用した Express 2 および Express 3 です。

いくつかの事実。

  • ノードは大きな v8 ヒープを処理できません。200 MB を超えると、CPU 使用率が増加し始めます。
  • ノードは常にメモリをリークしているように見えるか、少なくとも実際に使用せずに大きなヒープサイズを拡大しているようです。v8 プロファイリングまたは valgrind が js 空間や常駐ヒープにリークを示さないため、メモリの断片化が疑われます。初期の 0.8 はこの点でひどいもので、rss は 50MB のヒープで 1GB になることもありました。
  • 保留中のリクエストは追跡が困難です。特に私たちのアプリは長いポーリングベースであるため、これらを監視するためにミドルウェアを作成しました

私の提案。

  • マシンごとに複数のインスタンスを使用し、CPU ごとに少なくとも 1 つ使用します。セッションアフィニティを備えたhaproxy、nginxなどとのバランス
  • ハングした接続、つまり、コードがまったく応答しないか、遅延がしきい値を超えていることを報告するミドルウェアを作成する
  • 少なくとも毎週、頻繁にインスタンスを再起動します
  • 1 分に 1 プロセス モジュールでメモリ統計を出力する書き込みポーラー
  • プロセス管理を容易にするためにsupervisordとfabricを使用する

CPU、報告されたメモリ統計を監視し、しきい値で再起動します

于 2012-11-10T02:28:12.047 に答える
6

Web アプリの種類が NodeJS かそれ以外かに関係なく、負荷テストによって、アプリケーションに適切な量のサーバー リソースがあるかどうかがわかります。これについて最近見つけた優れた Web サイトはLoad Impactです。

答えるべき本当の質問は、同時ユーザー数の増加に伴い、ロード時間が増加し始めるのはいつですか? 一定数の同時ユーザーに到達すると転換点に達し、その後サーバーのパフォーマンスが低下し始めます。そのため、近い将来に Web サイトにアクセスすると予想されるユーザーの数に応じて負荷テストを行います。

予想されるユーザー数をどのように見積もることができますか?

ページに Google アナリティクスまたは別のアナリティクス パッケージをインストールする必要があります。このようにして、Web サイトに毎日何人のユーザーがアクセスしているか、月ごとのアクセス数の伸びを確認できます。これは、将来の予想されるアクセス数とサーバーの予想される負荷を予測するのに役立ちます。

ユーザー数がわかっていても、実際の負荷を見積もるにはどうすればよいですか?

その答えは、すべてのブラウザで利用できる F12 開発ツールにあります。Web サイトを任意のブラウザーで開き、F12 (Opera の場合は Ctrl+Shift+I) を押すと、ブラウザーの開発ツールが開きます。Firefox では Firebug がインストールされていることを確認してください。Chrome と Internet Explorer ではそのまま使用できます。[ネット]または[ネットワーク] タブに移動し、ページを更新します。これにより、HTTP リクエストの数、ページの読み込みごとの帯域幅の使用量が表示されます!

したがって、毎日のサーバー負荷を計算する式は簡単です。

ページ読み込みあたりの HTTP リクエスト数 X ユーザーあたりの 1 日あたりの平均ページ読み込み数 X 予想される同時ユーザー数 = 1 日あたりのサーバーへの HTTP リクエストの総数

と...

ページの読み込みごとに転送される MB 数 X ユーザーごとの 1 日あたりの平均ページ読み込み数 X 予想される同時ユーザー数 = 1 日あたりに必要な合計帯域幅

これらの数値を毎日計算し、それを数週間または数か月に推定する方が簡単だといつも思っていました.

于 2012-11-16T09:25:43.380 に答える
3

Node.js はシングル スレッドであるため、マシンの CPU ごとに必ずプロセスを開始する必要があります。クラスターはこれを行うための最良の方法であり、停止したワーカーを再起動し、応答しないワーカーを検出できるという追加の利点があります。

また、要求がタイムアウトし始めるか、合理的な応答時間と見なされる時間を超えるまで、負荷テストを実行する必要があります。これにより、サーバーが処理できる上限を知ることができます。ブリッツは、検討すべき多くのオプションの 1 つです。

Joyent の統計を使用したことはありませんが、NodeFlyとそのnode-nodefly-gcinfoは、ノード プロセスを監視するための優れたツールです。

于 2012-11-22T08:22:52.240 に答える