25个版本

0.7.0 2024年2月1日
0.6.1 2023年11月5日
0.6.0 2023年9月28日
0.5.5 2023年3月7日
0.1.14 2020年3月14日

#594 in 网络编程

Download history 1/week @ 2024-05-18 3/week @ 2024-05-25 9/week @ 2024-06-01 8/week @ 2024-06-08 2/week @ 2024-06-15 43/week @ 2024-06-29 1/week @ 2024-07-06 75/week @ 2024-07-27

每月119次下载

MIT许可证

60KB
977

s3-algo

rusoto之上,提供针对Amazon S3批量操作的高性能算法。通过可配置的超时/重试/退避算法实现可靠性和性能,适用于大量请求。通过每个完成的请求都会调用的闭包来密切监控进度,以提供准确的用户反馈。

https://docs.aws.amazon.com/AmazonS3/latest/dev/optimizing-performance-guidelines.html

  • 使用s3_upload_files上传多个文件。
  • 使用s3_list_objectss3_list_prefix列出文件,然后对所有文件执行删除或复制操作。

此crate处于起步阶段,我们欢迎PR、功能请求、API改进建议。

运行测试和示例

测试和示例都需要在本地9000端口运行S3服务,如minio。测试假设存在凭据配置文件 - 例如在~/.aws/credentials中。

[testing]
aws_access_key_id = 123456789
aws_secret_access_key = 123456789

列出、删除和复制对象

都是通过入口点s3_list_objects()s3_list_prefix()完成的,这些入口点返回一个可以删除和复制文件的ListObjects对象。示例

s3_list_prefix(s3, "test-bucket".to_string(), "some/prefix".to_string())
    .delete_all()
    .await
    .unwrap();

上传

s3_upload_files函数的功能

  • 尽可能通用,以支持许多用例。
  • 可以通过闭包从上传收集详细数据 - 可以选择使用这些数据来分析性能,例如实现实时进度百分比报告。
  • 退避机制
  • 快速。已实施多种机制,例如 积极的超时、并行化以及在上传时从文件系统流式传输文件。

算法细节

UploadConfig 的文档可能有助于阐明算法的组成部分。目前算法最重要的方面是决定超时值。也就是说,在再次尝试之前要等待多长时间。超时足够紧凑对于性能来说很重要。实现这一目的的主要机制是通过运行指数平均估计上传带宽(成功上传的单个文件的上传速度)。此外,在每次连续重试时,超时将按某个因子(退避)增加。

待考虑事项

  • 算法是否考虑了想要使用同一网络的其他进程?例如,在拥塞的情况下。它确实在请求失败后实施了增加的退避间隔,但应该在共享网络上测试其真实效果。

示例

perf_data

命令行界面,用于将任何目录上传到本地运行的 S3 服务(如 minio)的任何存储桶和前缀。示例

cargo run --example perf_data  -- -n 3 ./src test-bucket lala

打印

          attempts             bytes        success_ms          total_ms              MBps          MBps est
                 1              1990                32                32           0.06042           1.00000
                 1             24943                33                33           0.74043           1.00000
                 1              2383                29                29           0.08211           1.00000
                 1               417                13                13           0.03080           1.00000
                 1              8562                16                16           0.51480           1.00000

total_ms 是包括所有重试的总时间,而 success_ms 是最后一次尝试的时间。这两个时间之间的区别在实际案例中有用,其中 attempts 不总是 1

然后,您可以通过进入容器来验证上传是否发生。类似于以下内容

$ docker exec -it $(docker ps --filter "ancestor=minio" --format "{{.Names}}") bash
[user@144aff4dae5b ~]$ ls s3/
test-bucket/ 
[user@144aff4dae5b ~]$ ls s3/test-bucket/
lala

依赖项

~24–34MB
~470K SLoC