我需要加快我的 magento 安装速度，所以我打算将 'var/'（或仅 var/cache 和 var/sessions）的内容放在 tmpfs 上。
我还在亚马逊上购买了一个预留实例，所以我想保留足够数量的 RAM。我想启用 memcached、PHP Apc、MySQL 缓存和 HTTP 缓存。
我正在考虑具有以下规格的中型预留实例：
3.75 GB memory
2 EC2 Compute Unit (1 virtual core with 2 EC2 Compute Unit)
410 GB instance storage
32-bit or 64-bit platform
I/O Performance: Moderate
EBS-Optimized Available: No
API name: m1.medium
RAM 是否足以应用一个好的缓存系统？现在看（3 个月后）var 目录是 14gb，但我认为每 5/7 天清理一次也很好。
你对我有什么建议吗？
PS 商店将包含平均 100/150 种产品。
我认为搬到/varatmpfs可能不是你最大的瓶颈，而且可能比它的价值更麻烦。确保 Magento 缓存已启用并且您已启用 APC。
这篇文章涵盖了一些关于提高 Magento 性能的一般技巧：
我建议考虑设置像 Varnish 这样的反向代理。
如果您确实打算仅使用tmpfs内存中的 a，我建议您研究 Colin 的改进Zend_Cache_Backend_File
此外，我建议mytop您密切关注是否有任何地方可以优化应用程序本身的查询或my.cnf帮助缓解任何数据库瓶颈。
Session Digital 有一个关于优化 Magento 企业的很好的白皮书（虽然有些过时），同样可以应用于社区。正如白皮书中提到的，在我尝试过的所有方法中，Varnish 提供了最显着的响应时间增加。
希望这可以帮助！
首先，对这里的所有答案 +1。
如果您正在考虑在 tmpfs 之外运行 /var/，这可能是因为您听说过AWS 上糟糕的文件 IO，或者您自己遇到过问题。但是，/var/ 目录是您最不关心的 - Zend / Magento 的自动加载器对 IO 的负担更大。为了减轻您想要运行 APC 和编译的影响（假设您没有使用持久购物车）。
正如其他评论者所回应的那样，任何从缓存或内存运行的东西都会绕过 PHP，因此需要接触磁盘并引发 IO 问题。Varnish 是一种蛮力的方法，并且是在可扩展至数百万浏览量的大型网站上的出色工具；但我相信 Varnish 对 SSL 的限制以及我们 Magento 社区缺乏真正的文档和支持使其成为比实际替代方案更好的智力选择。
在运行 Magento Community 时，我更喜欢在 Medium 实例上运行 Tinybrick 的 Lightspeed on AWS - 这给了我最大的收益，而且它本身就是一个整页缓存。在此设置中，我每秒获得 200 多个并发页面，并且我没有运行 memcached 或使用编译。
http://www.tinybrick.com/improve-magentos-slow-performance.html/
在您的 AWS 实例中运行 memcached 时也要小心——我发现它可能会受到耗电的 Apache 的阻碍，在极少数情况下您没有准备好的缓存，这会在等待缓存响应时导致 Apache maxclients 问题. 如果你负担得起的话，我宁愿运行两个微型 Apache 实例，它们前面有一个共享的 memcached 会话存储和一个负载均衡器——不过，在一个单独的盒子上为数据库提供一些马力供它们共享。但是所有设置都是独一无二的，您的流量/使用情况将决定您需要什么。
我在 AWS 云中运行 Magento 已经 3 年了，并且取得了巨大的成功——我希望你也一样。干杯。