【问题标题】:How to calculate the optimum chunk size for uploading large files如何计算上传大文件的最佳块大小
【发布时间】:2011-04-10 01:40:05
【问题描述】:

是否存在处理大文件的最佳块大小之类的东西?我有一个上传服务 (WCF),用于接受数百兆字节的文件上传。

我尝试过 4KB、8KB 到 1MB 的块大小。更大的块大小有利于性能(更快的处理),但它是以内存为代价的。

那么,有没有办法在上传文件时计算出最佳的块大小。如何进行这样的计算?是否是可用内存和客户端、CPU 和网络带宽的组合决定了最佳大小?

干杯

编辑:可能应该提到客户端应用程序将在 Silverlight 中。

【问题讨论】:

    标签: c# asp.net silverlight wcf chunking


    【解决方案1】:

    如果您担心资源不足,那么最好通过根据系统的可用内存评估您的峰值上传并发性来确定最佳值。在您可能进行的任何计算中,您一次同时进行多少次上传将是关键的关键变量。您所要做的就是确保您有足够的内存来处理上传并发,而这很容易实现。内存很便宜,而且您很可能会在您的并发超出内存可用性的地步之前用完网络带宽。

    在性能方面,这不是您在应用设计和开发过程中真正可以优化的东西。你必须让系统到位,用户上传真实的文件,然后你才能监控实际的运行时性能。

    尝试匹配您网络的TCP/IP window size 的块大小。这几乎是您在设计时真正需要的最佳值。

    【讨论】:

    • 好吧,我更多地指的是客户端机器(我们无法控制)。如果我将块大小设置为 1MB,它将耗尽客户端计算机上的所有内存。但是,如果我将其设置为低,则需要很长时间才能处理。
    • 哦!使用客户端机器,它要简单得多。并发几乎不存在。只要您在获得它们后不将这些位保留在内存中,您几乎可以使用您想要的任何块大小。任何现代客户端,甚至是手机,都有足够的 CPU 和内存来处理一些文件,只要您在获取每个块后将比特流式传输到存储。我怀疑您是否会仅根据块大小在应用程序级别看到任何显着的性能差异。对于大文件,我会选择 1024KB 并收工。
    猜你喜欢
    • 2018-03-21
    • 2019-10-09
    • 2014-04-04
    • 1970-01-01
    • 1970-01-01
    • 2020-03-04
    • 2011-09-28
    • 2016-09-29
    • 1970-01-01
    相关资源
    最近更新 更多