|
1
5
memcache对于单独进程/请求中的大量读取很方便,您是使用大量不同的进程发送还是批量发送?在后一种情况下,忽略memcache。 本地include非常快,如果您经常访问该文件,您的操作系统甚至会为您缓存该文件,从而有效地从内存中读取该文件。没有测试是无法判断的,但我认为最大的速度增长将是在操作码缓存(例如apc)中拥有文件:内存中的本机格式。 另外,如果文件include是您的代码中的瓶颈,特别是在您发送邮件时,我会很惊讶。非常了解优化规则1:不要解决不存在的性能问题。 |
|
|
2
2
嗯,这是一个很难回答的问题。有很多变数处于危险之中。 对这些数据有很多要求吗(当我说很多的时候,我的意思是每秒超过一到两个)?如果是这样的话,memcache会得到一分… 您的驱动器是否具有高性能(SCSI或SAS、RAID 0或10)?如果是这样,文件可能会有点问题。 你有很多公羊吗?如果是这样,操作系统可以缓存更多的文件数据,因此文件所需的驱动器活动更少。 您有很多这些预先定义的消息吗?如果是这样,memcache的索引可能会有所不同… 您的memcache服务器只在localhost上吗?否则,memcache将失去网络延迟点。 底线是这样。除非你做了大量的查找(每秒很多次),否则两者都会很快(在合理范围内,小于10到20毫秒)。就个人而言,除非你每秒查找10封以上的电子邮件,否则坚持使用文件方法。它更容易维护(如果需要重新启动,您不必担心刷新memcache),而且更容易调试。记住:简单点…… |