python – Fabric：rsync_project vs upload_project的可伸缩性

2019年8月3日 198次阅读

我正在编写代码以使用Fabric部署到所有Web机器,并且想知道
rsync vs. upload project如何在并行化和最短时间方面工作.

有没有基准？

我可以并行rsync到100台机器吗？限制因素是什么？

  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只需要执行一次然后再执行sftp.或者上面显示的例子是多次？

结构是否会进行某种限制以确保网络不会受到限制？

有人可以帮忙吗？

最佳答案 在对rsync和upload_project进行基准测试之前,您必须知道rsync仅传输
differential data.当您的部署仅包含很少的更改时,Rsync将比upload_project更有效.

delete = True表示将远程删除本地删除的文件.这可能是你想要的.

如果你坚持,我不得不说基准测试结果将取决于它们的文件号和大小.例如,如果你有1K大小的1G文件,rsync将比upload_project慢得多.因为后者总是打包tar / gzip然后传输这个大文件.

最后,fabric没有“tar cache”,它会在每次部署时重复tar,因为the code写成：

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

但您可以添加一些缓存或手动注释掉它们.

对于网络事物,Fabric将它们留给sftp,它们具有Congestion窗口
确定网络没有窒息.

点赞