调用服务来处理大文件
本文关键字：文件 处理 服务 调用 | 更新日期: 2023-09-27 17:52:55
所以我有这个WCF服务，它为我提供了PDF处理功能。现在它接受并返回普通字节数组(byte[])，但这意味着它总是读取所有内容到内存，甚至当它处理流时，它必须将它们ToArray()到字节数组。问题是，这会导致内存不足问题和堆碎片。
我有两个选择来优化它，这样它就不会占用那么多内存:
- 使用流。虽然很诱人，但我可能不得不将其持久化到磁盘上，以便由PDF工具包进行处理。考虑到绑定数量有限，双工流和参数数量的限制，这也是一个非常挑剔的策略。
- 来回传递UNC文件路径。看起来很有希望，但事情很复杂，因为有人需要在使用后清理文件。
在优化资源使用(内存、网络、文件系统)方面，哪一种替代方案将获得最佳结果?
这是老派的，但我会选择"来回传递UNC文件路径"。幸运的是，我们开发人员对这种方法有几年的经验(参见:1980年左右Unix Version 7中的print spooler)。
我也会选择UNC文件路径选项。当我通过应用服务器将用户上传的文件从Web服务器传输到SharePoint时，我就使用了这种方法。Web服务器会将文件路径传递给应用服务器，然后应用服务器会拾取文件并将其加载到SP中。这是一个更好的选择，通过Web服务器通过Web服务调用将文件作为字节数组传递给应用服务器。
关于"有人需要清理文件之后"，如果你担心你的服务可能不总是做清理，例如，如果有一个例外，你总是可以有一个备份计划，并使用一些简单的东西，如powershell脚本与计划任务删除旧的文件，应该早些删除。
要考虑的一件事是文件名冲突的可能性。在我们的例子中，两个用户上传具有相同名称的单独文件是可行的，因此我们必须确保将正确的文件放入正确的SP文件夹中。我们通过让本地存储文件的web服务器，用GUID名称重命名文件，然后将新名称传递给应用服务器来解决这个问题。原始文件名作为元数据发送到应用服务器，以便它可以在加载到SP之前将文件重命名回其原始名称。