AWS CLI S3 CP性能非常缓慢

时间:2018-10-02 09:49:50

标签: amazon-web-services amazon-s3 aws-cli

我遇到了一个问题,即通过aws cli从AWS S3上进行上传和下载非常慢。非常慢,我的意思是一个211k文件始终需要2.3 s左右的时间,这表明平均下载速度低于500Kb / s,对于这么小的文件来说这是非常慢的。我的webapp严重依赖于内部API,并且我缩小了范围,该API的往返性能主要与从S3上传和下载文件有关。

一些细节:

  • 在AWS托管的EC2实例上使用最新版本的aws cli(aws-cli / 1.14.44 Python / 3.6.6,Linux / 4.15.0-34-generic botocore / 1.8.48)
  • 实例正在运行最新版本的Ubuntu(18.04)
  • 实例位于ap-southeast-2a(悉尼)
  • 实例通过最低特权策略(即,它需要访问的存储桶的最低权限)被授予基于角色的S3访问权限
  • 类型为t2.micro,其互联网带宽应为60Mb左右
  • S3存储桶位于ap-southeast-2
  • 加密(默认)和未加密文件的结果相同
  • 文件的结果相同,无论对象名称中是否随机包含字母数字字符
  • 即使多次尝试执行cp后,问题仍然持续存在,并且重新启动后cp尝试始终需要2.3s。
  • 这使我想知道S3或EC2实例(正在使用标准Internet网关)是否受到限制
  • 我已经测试过使用wget从同一实例将同一文件下载到Web服务器,这需要0.0008s(即8ms)

总结一下:

  • 通过AWS CLI从S3下载文件需要2.3秒(即2300ms)
  • 通过wget从Web服务器(> Internet> Cloudflare> AWS> LB> Apache)下载相同文件需要0.0008s(即8ms)

我需要提高AWS CLI S3的下载性能,因为该API将来会被大量使用。

任何建议将不胜感激。

4 个答案:

答案 0 :(得分:1)

好吧,这是事物的结合。

我以前在使用AWS PHP API SDK时遇到了问题(主要与复制文件时的孤立线程有关),因此出于简单性和可靠性的原因更改了API以使用AWS CLI,尽管它们可以工作,但我遇到了一些问题性能问题:

  • 首先,因为我的实例具有对S3存储桶的基于角色的访问权限,所以aws CLI大约需要1.7s来确定我的存储桶所在的区域。将CLI配置为指向默认区域可以克服这一点
  • 第二,因为PHP必须在运行exec()命令时调用一个全新的shell(例如exec(“ aws s3 cp s3://bucketname/objectname.txt /var/app_path/objectname.txt))我知道可以通过Gearman或类似工具卸载Shell命令,但是由于简单性是我的目标之一,所以我不想走这条路
  • 最后,由于AWS CLI使用Python,因此甚至在开始处理命令之前,仅需花费0.4s即可启动。看起来似乎很多,但是当我的API投入生产使用时,这将对用户和基础架构产生很大的影响

简而言之,我做了两件事:

  • 恢复使用AWS PHP API SDK代替AWS CLI
  • 在我的PHP代码中引用正确的S3区域名称

我的API现在的性能要好得多,即从2.3秒提高到平均约.07秒。

这并不能消除我原来的问题,但至少性能要好得多。

答案 1 :(得分:0)

听起来像我遇到类似的问题

我的aws s3 cp --recursive命令在进行大传输时现在也变得非常慢,并且也挂在了上次下载的文件上

aws cli版本缓慢且挂起 aws-cli / 1.16.23 Python / 2.7.15rc1 Linux / 4.15.0-1023-aws botocore / 1.12.13

此版本以前很好 aws-cli / 1.16.23 Python / 2.7.15rc1 Linux / 4.15.0-1021-aws botocore / 1.12.13

答案 2 :(得分:0)

我发现,如果尝试使用aws s3 cp下载对象,则当对象大小大于500MB时,下载将接近完成。

但是,直接使用get-object不会导致挂起或运行减慢。因此,不要使用

aws s3 cp s3://my-bucket/path/to/my/object .

获取对象

aws s3api get-object --bucket my-bucket --key path/to/my/object out-file

我没有减速。

答案 3 :(得分:0)

AWS S3 运行缓慢且极其复杂,您无法轻松搜索文件。如果与 cloudfront 一起使用,它会更快并且应该有优势,但是复杂性从非常复杂转变为非常复杂,因为缓存会混淆任何文件更改,并且使缓存无效是命中和未命中,除非您更改涉及更改文件名的文件名引用该文件的页面中的文件名。

在实践中,特别是如果您的所有或大部分流量与负载均衡器位于同一区域时,我发现即使位于同一区域的低规格 Web 服务器的速度也快 10 倍。如果您需要多个连接到公共卷的 Web 服务器,AWS 仅在某些区域提供此功能,因此我通过使用 NFS 在多个 Web 服务器上共享卷来解决此问题。这为您提供了一个安装在服务器上的文件系统,您可以登录并列出和查找文件。 S3 已成为解决几十年前更好解决的问题的交钥匙解决方案。