【发布时间】：2010-06-04 22:29:53
【问题描述】：
我正在尝试加载预定义的电子邮件以发送出去——我的问题是，我是否应该缓存所有电子邮件，而不仅仅是包含包含电子邮件变量的文件，并且只调用一次一天还是什么？
【问题讨论】：
【发布时间】：2010-06-04 22:29:53
【问题描述】：
Memcache 可以方便地在单独的进程/请求中进行大量读取，您是使用许多不同的进程还是批量发送？在后一种情况下，忘记 memcache。
本地包含非常快，如果您经常访问该文件，您的操作系统甚至会为您缓存该文件，从而有效地从内存中读取它。没有测试就无法判断，但我认为最大的速度提升是将文件放在操作码缓存（例如 APC）中：本机格式和内存中。
再一次，如果文件包含是您代码中的瓶颈，我会感到惊讶，尤其是在您发送邮件时。非常注意优化规则 #1：不要解决不存在的性能问题。
【讨论】：
-
从未听说过优化规则 #1 - 谢谢！我正在开发一个新系统，所以我只是想为未来做准备，但很高兴知道！ -- 它们是单独的请求。每次有人在我们的网站上注册或我们必须发送电子邮件。
-
该死的，我几乎要这么说，尤其是最后一点。为你 +1
-
我一直认为优化的第一条规则是最大可能的收获是从非工作系统过渡到工作系统（又名：过早的优化是万恶之源）...... ;-)
-
说得很好“不要解决不存在的性能问题”，是的，这应该是优化规则#1
嗯，这是一个很难回答的问题。有很多变数。
对这些数据的请求是否很多（当我说很多时，我的意思是每秒超过一两个）？如果是这样的话，Memcache 会得到一个点...
您的驱动器是否具有高性能（SCSI 或 SAS、RAID 0 或 10）？如果是这样，文件可能会得到一分。
你有很多内存吗？如果是这样，操作系统可以缓存更多的文件数据，因此文件需要更少的驱动器活动。
您有很多这些预定义的消息吗？如果是这样，Memcache 的索引可能会有所作为...
您的 Memcache 服务器是否仅在本地主机上？否则，Memcache 将因网络延迟而失去一分。
底线是这样的。除非您进行大量查找（每秒多次），否则两者都将同样快（在合理范围内，不到 10 到 20 毫秒）。就个人而言，除非您每秒进行超过 10 次 EMAIL 查找，否则请坚持使用文件方法。它更易于维护（如果需要重新启动，您不必担心刷新 Memcache），并且更易于调试。请记住：保持简单...
【讨论】：
-
谢谢你——我不是服务器管理员，也没有设置服务器，所以我对驱动器一无所知。 RAM 肯定很低（我相信 2-4 gbs）而且它是 localhost。我暂时将其保留在本地，如果它成为一个问题，那么我会更多地研究它，但我感觉其他事情会很快导致问题。