AWS Cloud9环境文件上传速度慢的原因与优化方案咨询

大量小文件上传缓慢是Cloud9 Web端上传功能的已知问题 #

你当前遇到的慢传输问题和实例规格、带宽配置无关：t3.medium的EBS优化带宽、实例网络性能完全可以支撑这批文件的传输，你之前从GitLab全量拉取仅耗时2分钟也能佐证这一点。
慢的核心原因是Cloud9 Web IDE自带的本地文件上传功能，走的是SSM会话承载的IDE控制通道，采用单文件串行传输逻辑，每个文件都要单独完成握手、权限校验、落盘确认流程，6.5万个小文件的流程开销占了总耗时的95%以上，实际有效数据传输的占比极低，才会出现总耗时数小时的情况。

直接在Cloud9环境内克隆Git仓库可以实现传输效率的显著提升 #

这是你当前场景下的最优方案，传输速度可以达到Web零散上传的几十倍，总耗时基本和你之前测试的GitLab拉取速度持平，2-3分钟即可完成全量文件同步：

• 克隆操作是Cloud9实例主动向代码仓库发起请求，不需要调整实例的无入站隔离配置，符合安全要求
• Git传输过程会对批量文件做压缩打包，不存在单文件反复握手的开销，到实例本地后再批量解压落盘，磁盘IO和网络利用率都能跑满
• 私仓场景直接在Cloud9终端配置HTTPS访问令牌或者部署密钥即可，不需要额外做网络打通

其他可选用的提速手段 #

如果你有无法走Git仓库、必须从本地上传文件的场景，可以按优先级选以下方案：

• 本地提前将所有待上传文件打包为单个tar.gz或者zip压缩包，通过Web端上传单个压缩包后，在Cloud9终端执行解压命令，总耗时可以压缩到10分钟以内，彻底规避单文件串行传输的额外开销
• 配置SSM端口转发后通过scp/rsync传输文件，这类工具支持多文件批量流水线传输，比Web端零散上传效率高10倍以上，但传输大量小文件的速度依然不如先打包再传、或者直接Git克隆
• 临时需要同步少量改动文件时，优先用rsync的增量同步功能，不要反复全量上传文件

内容的提问来源于stack exchange，提问作者JCERS