让我们来分解一下：
-
我将做出的假设（请检查它们）
- 您正在相当强大的 EC2 实例上运行，例如 m3.large
- 您正在运行类似 APC 的 PHP 缓存
- 您正在使用Magento编译器系统->工具->编译
- 您正在使用 Apache 网络服务器
- “5到10秒从服务器获得响应”是指响应时间，不包括图像和CSS和JS下载到浏览器的时间
- 您有产品和类别的平面表（但是如果您的缓存工作正常，那么这不应该影响速度。您还应该在没有平面表的情况下运行测试；它们并不总是更快）
- 您的网络服务器配置针对“保持活动状态”和“使标头过期”的大流量进行了优化
- 三重检查您的全页缓存
关于你的问题，真正奇怪的是你说你有一个完整的页面缓存，但产品前端页面在服务器将它们发送到浏览器之前需要 5 到 10 秒。
在我看来，这意味着您的整页缓存不起作用。如果正确实现，全页缓存将直接从 Apache 提供页面服务without运行 Magento 应用程序（Mage.php），这就是为什么它这么快。这意味着请求缓存页面时没有任何开销，这就是为什么全页面缓存系统的“请求”时间应小于 0.25 秒，有时小于 0.1 秒。
我建议您关闭全页缓存，看看它有何不同。检查您的主题和缓存文档，了解它们如何处理不可缓存的页面内容（例如购物篮摘要和显示用户名） - 但任何缓存都应该缓存所有产品块，因此制作前端产品页面应该访问缓存而不是访问数据库。
当然，如果您有 20000 个产品（或 100,000？= 20,000 个配置 + 4*20,000 个简单产品），那么每个页面都需要访问一次才能填充您的缓存，因此您可能需要设置一个夜间运行的链接检查器以命中所有 URL 并启动每个类别和/或产品页面的完整页面缓存。
- 检查你的主题 .phtml 文件中是否存在可怕的内容
Mage::getModel(catalog/product)->load($_product->getId())
此行会访问您的数据库hard如果您对类别页面上的每个产品都这样做，那么就会带来麻烦。如果您的主题正在使用->load()然后与您的主题设计师讨论如何仅使用他们需要的属性创建集合。但是，如果您有页面缓存，那么这不一定重要（因此我认为您的缓存不起作用）。
- 看看你的
core_url_rewrite table
由于您拥有的所有产品，这张桌子很可能会很大。它可能有助于使您的简单产品不可见，而仅使可配置项在目录和搜索中可见。检查表有多少行，截断它，然后转到 Magento 管理并重新索引重写 - 这将重新构建表，您可以查看它是否有更少的行（Magento 似乎将大量重写加倍）时间）。此外，您还将获得 Magento 中每个商店的全套重写，因此请删除您不使用的任何商店。
现在关于缓存的另一个注释。我找到了core_url_rewrite瓶颈之一，所以我在周围放置了一个缓存.phtml生成商店菜单，因为菜单变化不大，这样做可以节省大量数据库时间。但是，如果您已经有缓存，那么这不会成为问题，除非您的缓存无法正常工作或设置不正确。
- 让 Varien 分析器正常工作
这样你就可以看到为什么 magento 花了这么长时间。我认为您需要关闭缓存才能使其工作。这是一个速度分析的有用工具 http://www.mgt-commerce.com/magento-developer-toolbar.html，但也存在其他免费工具，实际上您可以在没有工具的情况下使用 Varien 分析器。该工具将为您指示在页面上构建需要很长时间的内容（但是如果您的缓存工作正常，那么构建页面故事需要多长时间并不重要，因为页面将从缓存中提供服务这就是为什么我认为你的缓存不起作用）。
- 你说“MySQL 数据库运行良好 - 我可以进行查询并快速返回它们。”
但这并不是测试您的数据库是否正常工作的标准。也许您知道这一切，但您可以使用 phpmyadmin 来检查您的 my.cnf 设置是否已优化。 phpmyadmin->status->advisor 会给你提示innodb_buffer_pool and key_buffer_size and table_cache。无论你做什么，Magento 都没有优化索引，所以 mysql 总是有很多工作要做。您可能想像建议的那样查看您的 innodb 文件here http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/ (and I 这也是必读的 http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html），但是如果你的 ibdata1 文件和 innodb 日志文件不是太大，并且慢速查询日志中没有任何内容，并且你没有遭受太多的锁等待，那么运行可能没有优势'innodb_file_per_table'。有人建议innodb_file_format=Barracuda https://dev.mysql.com/doc/refman/5.5/en/innodb-file-format.html，但我认为我们正在进行微调以挤出最后一毫秒。
这里有一个关于 ibdata 文件、表优化和 innodb 管理的真正优秀的 Stackoverflow 问答 https://stackoverflow.com/questions/3927690/howto-clean-a-mysql-innodb-storage-engine。警告：我不知道为 Magento 设置的最佳 innodb，但是当我读到类似的文章时，我认为这似乎是正确的方法。
无论如何，你应该确保你的 my.cnf 设置为以最佳方式使用可用的内存（没有任何魔法设置，我不能告诉你，但请研究这些参数：）。
max_allowed_packet =
table_cache =
sort_buffer_size =
read_buffer_size =
read_rnd_buffer_size =
myisam_sort_buffer_size =
tmp_table_size =
max_heap_table_size =
query_cache_size =
query_cache_type =
thread_cache_size =
innodb_fast_shutdown = 0
innodb_file_per_table
innodb_buffer_pool_size =
innodb_additional_mem_pool_size =
innodb_log_file_size =
innodb_log_buffer_size =
innodb_flush_log_at_trx_commit =
innodb_lock_wait_timeout =
innodb_thread_concurrency =
skip-external-locking
max_connections =
read_buffer_size =
sort_buffer_size =
key_buffer_size =
- 通过 SSH 连接到您的盒子
并运行'top' 来观察 http 守护进程和 mysql 服务器的内存和 cpu 负载 - 我有时会在运行链接检查器时这样做，这样我就可以看到系统至少有一点负载。如果负载很少，可能您的 httpd.conf 和 my.cnf 未设置为利用可用的 CPU 和内存。如果您的 CPU 和内存已达到极限，那么maybe你需要更大的盒子，但如果你的整页缓存工作正常......
Using top还将显示您的服务器是否已受到损害，并且所有 CPU 周期是否都被某些脚本小子比特币矿工占用。
- 往上面砸钱
去 M3 Extra Large 盒子，打电话给 Percona 并听取它所有的建议，获取一吨 RAM 并在 ramdisk 中运行你的数据库，从 Facebook 雇佣一些孩子在 HHVM 上运行 Magento，或者说“去他妈的”并付钱给 Magento 专家托管公司为您完成这一切。但是如果你的整页缓存正在工作......
----------
无论如何，我希望你玩得开心。我喜欢让 Magento 运行得更快。有大量的旋钮需要调整，看到页面加载时间一点点下降是非常值得的。
哦，我认为全页缓存不会帮助缓慢的管理区域，但有一些模块可以使管理大型产品目录变得更加简单。
