サーバー¹をpython port of mechanize - multi-mechanize でテストしました。いくつかの非常に簡単なテストを実行しました-しかし、常に10MBからいくつかに低下しますアップロード帯域幅のkb。そして私は理由がわかりません。
3分15分でも30分でも、結果に違いはありません。以下の分析でわかるように、110秒から120秒の間に常に帯域幅がほぼゼロに低下します。私は短期間の選択をしたので、ドロップを見つけるのは簡単です。
Htopのチェックでは、特別なことは何も示されていません。コアは2〜7%で実行されています。
メモリ使用量は、常に2048mb保証メモリの約1000mb(+ -100)です。
トップをチェックすると、アップロードが10メガバイトから数キロバイトに約10秒間(110〜120秒)低下する以外に特別なことは何もありません。
すべてのcronジョブ/不要なタスクが無効になります。すべてのページ(フロント/ランダム)が利用可能です。各リクエストはhttpレスポンスコード200で応答されます。ApacheとMySQLのエラーログは空です。
私はやって学ぶ管理者なので、もっと関連性のある情報があるかどうかわかりません。ロードされたApachemodは関連していますか?私がすべての重要な事実に言及したことを望みます。
[global]
run_time = 180
rampup = 0
results_ts_interval = 10
progress_bar = on
console_logging = off
xml_report = off
[user_group-1]
threads = 10
script = frontpage.py
[user_group-2]
threads = 10
script = randompost.py
import mechanize
class Transaction(object):
def run(self):
br = mechanize.Browser()
br.set_handle_robots(False)
resp = br.open('http://Host.domain.tld/')
resp.read()
assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
assert ('Example Web Page' in resp.get_data())
実際にはフロントページと同じですが、ランダムなページがあります
import mechanize
import random
pages = [
'...',
'...',
'...',
# ...
]
class Transaction(object):
def run(self):
br = mechanize.Browser()
br.set_handle_robots(False)
resp = br.open(random.choice(pages))
resp.read()
assert (resp.code == 200), 'Bad Response: HTTP %s' % resp.code
assert ('Example Web Page' in resp.get_data())
@linuxdevopsが述べたように、私はscpとftpでファイルをダウンロードしようとしました。私のテストには10MBのファイルと私のウェブサイトのフォルダが含まれていました-1-1xxkbからの多くのファイルを意味します。転送の悪用や目立ったラグはありませんでした。 FTP/SCP転送の一貫性を判断するためのより専門的な方法があるかどうかはわかりません。
¹仮想ホストの仕様
開始するのに適した場所は、netperfのようなツールを使用することです。それを見つけるためにグーグル
クライアントからnetperfを実行します:netperf -H <serverIP> -f M -l 240 -- -s 4194304
-f M
(出力をMB /秒で表示)-l
(秒単位の長さ)--
(オプションは2つのダッシュの後に続きます)-s
(ソケットサイズ)これは、適切なソケット/バッファサイズを見つける簡単な方法です。たとえば、Windowsのデフォルトのソケットサイズはわずか8192です。ドラッグアンドドロップを使用したコピーでは、このデフォルトのサイズが使用され、最大で約22MB /秒になります。これを64kに増やすと、100〜120 MB/sが表示されるようになります。最近のほとんどのソフトウェアでは、これを変更したり、テスト済みのスイートスポットをハードコーディングしたりできます。したがって、winscp、filezilla、またはこれらのファイル転送にユーティリティを使用している場合は、LinuxではTCPバッファ、Windowsではwinsockバッファを確認する必要があります。
Linuxの例:/etc/sysctl.conf
net.ipv4.tcp_rmem = 4194304 4194304 4194304
net.ipv4.tcp_wmem = 4194304 4194304 4194304
ウィンドウズ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters
DefaultReceiveWindow = 65536
DefaultSendWindow = 65536
リブート
Netperfを120秒以上実行でき、トラフが表示されないが、実際のデータをディスクにコピーしても表示される場合は、ディスクのトラブルシューティングに進むことができます。さまざまなバッファ/ソケットサイズを試しても減少が見られる場合、次のステップはパケットキャプチャです。
仮想ホスト上:
tcpdump -i <interface> -vvv -nn -s0 port 12865 -w /desiredDir/troughTest.cap
netserver
netperf -H <serverIP> -f M -l 300 -- -s 4194304
しばらく実行してからctrl-cを実行するか、十分なパケットがあると思われるときに強制終了します。最後に、tcpdumpをctrl-cし、/ desiredDir/troughTest.capファイルをラップトップ/ワークステーションに転送します。まだインストールしていない場合はwiresharkをインストールし、パケットを分析します。