4

私はFabricを使用してすべてのWebマシンにデプロイするコードを書いていますが、並列化と最短時間の観点から、rsyncとuploadプロジェクトがどのように機能するのか疑問に思っていました。

ベンチマークはありますか？

100台のマシンに並行してrsyncできますか？制限要因は何ですか？

  rsync_project(
        env.root,
        exclude=RSYNC_EXCLUDE,
        delete=True,
        extra_opts=extra_opts,
    )

同様に、upload_projectの制限要因は何ですか？数に関するsftpの制限は何ですか？ 

@parallel
def testapp():
    with cd('~/projects'):
        upload_project('./receiver', '/home/sysadmin/projects')

予感の観点からは、tarは1回だけ実行してから、sftpを実行する必要があるため、アップロードプロジェクトの方が優れているはずです。それとも、上記の例では複数回ですか？

ネットワークが限界まで詰まらないようにするために、ファブリックはある種のスロットルを実行しますか？

誰かがこれを手伝ってくれる？

4

1 に答える 1

2

ベンチマークrsyncとupload_projectの前に、rsyncが差分データのみを送信することを知っておく必要があります。デプロイメントに変更がほとんど含まれていない場合、Rsyncはupload_projectよりも非常に効率的になります。

delete = Trueは、ローカルで削除されたファイルがリモートで削除されることを意味します。それはおそらくあなたが望むものです。

あなたが主張するならば、私はベンチマーク結果がファイル数とそれらのサイズに依存すると言わなければなりません。たとえば、1Gの1Kサイズのファイルがある場合、rsyncはupload_projectよりもはるかに遅くなります。後者は常にtar/gzipをパックしてから、この大きなファイルを送信するためです。

最後に、ファブリックには「tarキャッシュ」がありません。コードは次のように記述されているため、デプロイごとにtarが繰り返されます。

    finally:
        run("rm -f %s" % tar_file)
finally:
    local("rm -rf %s" % tmp_folder)

ただし、キャッシュを追加することも、手動でコメントアウトすることもできます。

ネットワークの場合、ファブリックは、ネットワークが詰まっていないことを確認するために、輻輳ウィンドウがあるsftpにそれらを残します。

于 2012-05-28T17:30:52.243 に答える