【问题标题】:MD5 generation overheat - Web APIMD5 生成过热 - Web API
【发布时间】:2016-05-09 18:26:09
【问题描述】:

为了简短而坚定:

我有一个返回特定文件的 md5 的 api。这些文件大约 50 - 100 MB 大。现在我的问题是:

什么需要更少的资源/风格更好:

  1. 为每个 GET 生成文件的 md5
  2. 在第一次 GET 请求时生成 md5,并使用 FileSystemWatcher 监视文件的更改并在文件更改时刷新 md5

有人告诉我,多次生成 md5可能会导致过热。

【问题讨论】:

  • 第二总是更好,计算量更少,速度更快。
  • 计算导致过热?这是现代计算机的真正问题吗?
  • @aaaabbbb 我们讨论的是小型 Web 应用程序,而不是桌面应用程序。如果有办法减少精力,为什么还要浪费内存和处理能力?即使 C# 的性能非常好,您在开发应用程序时也应该关注性能。
  • 所以你的“过热”不是字面意思。
  • @aaaabbbb 好吧,如果有人喜欢按 F5,可能会导致严重过热

标签: c# asp.net hash md5


【解决方案1】:

第二个选项总是更快,具体取决于文件更改的频率。

您拥有的处理消耗最多的操作是 MD5 散列。如果您别无选择,只能使用 MD5 对文件进行哈希处理,您应该尽一切可能减少执行此操作的次数。理想的情况是只做一次,这正是选项 2 要做的事情。

这是假设文件不会更改,但产生过热的机会肯定比选项 1 低得多,即使您每 5 分钟更改一次文件。

【讨论】:

  • 由于文件夹内容只会偶尔更改,因此第二个选项肯定会更好。感谢您的提示!
【解决方案2】:

最好的方法是预先计算MD5,并将MD5与主文件一起保存。

在第一次调用时动态计算它会增加复杂性和处理时间,这很容易避免。

【讨论】:

  • 这样会更好,你是对的。但是由于文件不经常更改,因此 web 管理员每次生成 md5 比在应用程序中生成它更烦人。如果我必须做一个真正的商业解决方案,我会像你说的那样做,但由于这不是在公司中使用,我认为一次性一代是可以接受的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-10-23
  • 1970-01-01
  • 2020-12-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-24
相关资源
最近更新 更多