0

私は pingdom.com に似たシステムを構築しています。そこでは、5 分ごとに稼働時間をチェックするために約 10,000 のドメインがあります。チェックを実行するためにec2マイクロインスタンスを使用しています。チェック URL とその最終チェック時刻は mongodb に保存されます。ノード プロセスは、過去 5 分間に処理されなかった処理の上位 n 個のチェックを行い、URL 要求は非同期で行われます。ノード リクエスト ライブラリを使用しており、URL チェック コードは次のようになります。

var request = require("request");

var options = {
    url: url,
    headers: {
        'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
        'Accept-Encoding': 'gzip,deflate,sdch',
        'User-Agent': 'Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36'
    },
    timeout: 10000,
    maxRedirects: 10,
    pool: false,
    strictSSL: false
};

request(options, function (error, response, body) {
    ...
});

稼働時間チェックのために異なるドメインに 10 を超えるリクエストを同時に行うと、同時リクエストの数が増えるにつれて、これらのドメインの応答時間が遅くなることに気付きました。ノードが非同期であるため、応答時間が増加するべきではないと考えました。node-curl ライブラリも試してみようと思っていますが、その前にここで何か間違っているか確認したいと思います。

ulimit と pool.maxConnection の制限を微調整しようとしましたが、うまくいきませんでした。EC2 インスタンスの数を増やせば、許容できる応答時間で 5 分間に 10,000 のチェックを達成できることはわかっていますが、pingdom などのサービスには対処すべきチェックがさらに多くあると思います。稼働時間チェック インスタンスの増加とは別に、システム。

4

1 に答える 1

0

1 つのインスタンスでノード サーバーの小さなクラスターを試してみることをお勧めします。それぞれ異なるプロセス/スレッドを利用できます。1 つのインスタンスがコントローラーとして機能し、redis pub/sub またはその他の手段を介してコマンドを送信できます。ただし、ボトルネックが何であるかはわかりません。マイクロ インスタンスの帯域幅の問題である可能性があります。おそらく、コードの最も遅いビットがどこにあるかを特定するいくつかのテストを実行する必要があります。

于 2014-03-15T22:36:55.893 に答える