使用TransportUtility
类将文件上传到S3时,可以选择使用FilePath
或输入流。我使用多部分上传。
我上传了各种各样的东西,其中一些是磁盘上的文件,另一些是原始流。我目前正在使用InputStream
种类来处理所有内容,这种方法很正常,但我想知道是否应该进一步专门化这种方法。对于磁盘上的文件,我基本上使用File.OpenRead
并将该流传递给转移请求的InputStream
。
是否有任何性能提升或以其他方式优先使用FilePath
方法而不是已知输入为文件的InputStream
方法。
简而言之:这是同一件事吗
using (var fs = File.OpenRead("some path"))
{
var uploadMultipartRequest = new TransferUtilityUploadRequest
{
BucketName = "defaultBucket",
Key = "key",
InputStream = fs,
PartSize = partSize
};
using (var transferUtility = new TransferUtility(s3Client))
{
await transferUtility.UploadAsync(uploadMultipartRequest);
}
}
作为:
var uploadMultipartRequest = new TransferUtilityUploadRequest
{
BucketName = "defaultBucket",
Key = "key",
FilePath = "some path",
PartSize = partSize
};
using (var transferUtility = new TransferUtility(s3Client))
{
await transferUtility.UploadAsync(uploadMultipartRequest);
}
或两者之间有什么显着差异?我知道文件是否很大,并且可能更喜欢基于此的一种或另一种方法。
编辑:我还对S3Client进行了一些反编译,确实在传输的并发级别方面确实存在一些差异,如{{1 }}
MultipartUploadCommand.cs
答案 0 :(得分:1)
来自TransferUtility documentation:
通过指定文件路径而不是a来上载大文件时 stream,TransferUtility使用多个线程上传多个部分 一次上传一次。处理大内容时和 高带宽,这可以显着提高吞吐量。
这说明使用文件路径将使用MultiPart上传,但使用流不会。
但是当我读完这个Upload Method (stream, bucketName, key)时:
上传指定流的内容。对于大型上传, 文件将使用Amazon S3的multipart进行划分和上传 API。这些部件将在Amazon S3中重新组合为一个对象。
这意味着MultiPart也用于Streams 如果文件大小超过100MB http://docs.aws.amazon.com/AmazonS3/latest/dev/uploadobjusingmpu.html
,亚马逊建议使用MultiPart上传分段上传允许您将一个对象上传为一组 部分。每个部分都是对象数据的连续部分。您可以 独立地以任何顺序上传这些对象部分。如果 任何部分的传输失败,你可以重新传输该部分 影响其他部分。在上传对象的所有部分后, Amazon S3组装这些部件并创建对象。一般来说, 当您的对象大小达到100 MB时,您应该考虑使用 分段上传而不是将对象上传到单个中 操作
使用分段上传具有以下优势:
提高吞吐量 - 您可以并行上传部件以进行改进 吞吐量。从任何网络问题中快速恢复 - 零件尺寸更小 最大限度地减少因网络而重新启动失败上传的影响 错误。暂停和恢复对象上传 - 您可以上传对象部分 随着时间的推移。一旦你启动分段上传,就没有到期; 您必须明确填写或中止分段上传。开始吧 在知道最终对象大小之前上传 - 您可以上传对象 当你创造它时。
因此,基于Amazon S3,使用Stream或File Path之间没有什么不同,但它可能会根据您的代码和操作系统产生轻微的性能差异。
答案 1 :(得分:0)
我认为不同之处可能在于它们都使用分段上传API,但是使用FilePath
允许并发上传
使用流作为数据源时,TransferUtility 类不进行并发上传。
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingTheMPDotNetAPI.html