我首先要说的是,这比盲目地联合byte[]
起来要困难一些。
我的总体目标是优化当前将许多 512 字节页面上传到 Web 服务器(Azure Page Blob)的应用程序,并将其减少到 4Megs 或更少的单个大型上传。有关原因的更多背景信息,请参阅此问题底部的链接。
原因的简短答案:这种优化将提高速度(更少的 IO)并通过使用 Azure 稀疏文件长期节省资金
现在了解详情:
班级将需要
接受数据并将其存储(定义为
alignment start
、alignment stop
的数据以及随附的有效负载。N 条数据到达后,或
event
发生一次,ProcessData()
。这意味着是时候根据边界组装数据了( 的停止值blob1
必须与 的开始值对齐blob2
)连续的数据实际上可能无序到达。
非连续数据被定义为调用应用程序在发生之前没有发送它
processData()
。此外,如果整个 512 字节范围 == 零,则得到特殊处理,并被视为非连续的。我们正在处理 byte[] 的类型,因此这里的有效列表可能很复杂。我想避免不必要的数组副本和扩展。
说得通?(像泥一样,我希望不是)
到目前为止,我最接近的是编写方法签名:(我知道跛脚)
// This can't be bigger than 4Mb, or smaller than 512
byte[] BigBlobToUpload = new byte[];
/// <summary>
/// Collects consecutive data ranges that will be uploaded
/// </summary>
/// <param name="NameOfTarget">The name of the target (unique per host)</param>
/// <param name="range">The data to be collected, in 512K multiples</param>
/// <param name="offsetToTransfer">The "start point" or offset of the data stored in range to be included. Almost always 0.</param>
/// <param name="sizeToTransfer">The length, or end of the range to include. Almost always 512.</param>
/// <param name="cloudOffset">The location this data should be placed in the BigBlobToUpload global var for eventual upload</param>
private void AddToQueue(string NameOfTarget, byte[] range, int offsetToTransfer, int sizeToTransfer, int cloudOffset)
{
}
我只需要有人指导我如何有效地跟踪这些事情......我可以从那里处理它。即使是抽象的方向也会有所帮助
有人可以让我了解我应该如何跟踪和有条件地连接连续数据范围的正确概念方向吗?
更不用说我试图拥有仅在需要时扩展或复制数组的有效逻辑。