1

所以我有这个 WCF 服务，它为我提供了 PDF 处理功能。现在它正在接受并返回纯字节数组（byte[]），但这意味着它总是将所有内容读取到内存中，即使在处理流时，它也必须将它们 ToArray() 到字节数组。问题是，这会导致内存不足和堆碎片。

我有两种选择来优化它，这样它就不会使用太多内存：

  • 使用流。虽然很诱人，但我可能不得不将它保存到磁盘上以供 PDF 工具包处理。考虑到绑定数量有限以及双工流和参数数量的限制，这也是一个非常挑剔的策略。
  • 来回传递 UNC 文件路径。看起来很有希望，但会使事情复杂化，因为有人需要在使用后清理文件。

在优化资源使用（内存、网络、文件系统）方面，哪种替代方案会取得最佳效果？

4

2 回答 2

3

这是老派，但我会选择“来回传递 UNC 文件路径”。幸运的是，我们的开发人员已经有几年使用这种方法的经验（请参阅： 1980 年左右 Unix 版本 7 中的 print spooler）。

于 2013-01-14T21:25:00.200 回答
2

我也会选择UNC 文件路径选项。在通过应用程序服务器将用户上传的文件从 Web 服务器传输到 SharePoint 时，我使用了这个。Web 服务器会将文件路径传递给应用服务器，然后应用服务器会拾取文件并将其加载到 SP。通过从 Web 服务器到应用服务器的 Web 服务调用将文件作为字节数组传递是一个更好的选择。

关于“之后有人需要清理文件”，如果您担心您的服务可能不会总是进行清理，例如如果出现异常，您可以随时制定备份计划并使用一些简单的东西，例如带有计划任务的 powershell 脚本删除应该早先删除的旧文件。

不过要考虑的一件事是文件名冲突的可能性。在我们的案例中，两个用户上传具有相同名称的单独文件是可行的，因此我们必须确保将正确的文件放入正确的 SP 文件夹中。我们通过在本地存储文件的 Web 服务器解决了这个问题，使用 GUID 名称重命名文件，然后将新名称传递给 App Server。原始文件名作为元数据发送到 App Server，以便它可以在加载到 SP 之前将文件重命名为其原始名称。

于 2013-01-14T22:40:46.790 回答