我遇到了一个问题,即通过aws cli从AWS S3上进行上传和下载非常慢。非常慢,我的意思是一个211k文件始终需要2.3 s左右的时间,这表明平均下载速度低于500Kb / s,对于这么小的文件来说这是非常慢的。我的webapp严重依赖于内部API,并且我缩小了范围,该API的往返性能主要与从S3上传和下载文件有关。
一些细节:
总结一下:
我需要提高AWS CLI S3的下载性能,因为该API将来会被大量使用。
任何建议将不胜感激。
答案 0 :(得分:1)
好吧,这是事物的结合。
我以前在使用AWS PHP API SDK时遇到了问题(主要与复制文件时的孤立线程有关),因此出于简单性和可靠性的原因更改了API以使用AWS CLI,尽管它们可以工作,但我遇到了一些问题性能问题:
简而言之,我做了两件事:
我的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 已成为解决几十年前更好解决的问题的交钥匙解决方案。