结构：rsync_project vs upload_proj的可伸缩性

Question

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

有什么基准吗？在

我能并行同步到100台机器吗？限制因素是什么？在

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

同样，upload_项目的限制因素是什么？sftp的数量限制是多少？在

^{pr2}$

从预感的角度来看，上传项目应该更好，因为tar只需要完成一次，然后是它的sftp。或者是多次出现在上面的例子中？在

fabric是否会进行某种节流以确保网络不会阻塞到极限？在

有人能帮忙吗？在

Answer 1

在对rsync和upload项目进行基准测试之前，您必须知道rsync只传输differential data。当您的部署只包含很少的更改时，Rsync将比upload_项目更高效。在

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

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

最后，fabric没有“tar缓存”，它会在每次部署时重复tar，因为the code被写为：

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

但是你可以添加一些缓存或者手动注释掉它们。在

对于网络事物，fabric将它们交给sftp，sftp具有拥塞窗口 网络没有阻塞。在