让我们分解一下：
-
我将做出的假设（请检查它们）
- 您在相当强大的 EC2 实例上运行，例如 m3.large
- 您正在运行像 APC 这样的 PHP 缓存
- 您正在使用 Magento 编译器系统->工具->编译
- 您正在使用 Apache 网络服务器
- '5 到 10 秒得到服务器响应'是指响应时间，不包括图片和 CSS 和 JS 下载到浏览器的时间
- 您有产品和类别的平面表（但如果您的缓存工作正常，那么这不应该影响速度。您还应该在没有平面表的情况下运行测试；它们并不总是更快）
- 您的网络服务器配置已针对“keep alives”和“expires headers”的大流量进行了优化
- 三重检查您的整页缓存
关于你的问题，真正奇怪的是你说你有一个完整的页面缓存，但产品前端页面在服务器将它们发送到浏览器之前需要 5 到 10 秒。
在我看来，这意味着您的整页缓存不起作用。如果正确实施，完整页面缓存将直接从 Apache 提供页面，根本不运行 Magento 应用程序 (Mage.php)，这就是它如此快速的原因。这意味着请求缓存页面时没有开销，这就是为什么整页缓存系统的“请求”时间应该小于 0.25 秒，有时小于 0.1 秒。
我建议您关闭整页缓存，看看有什么不同。检查您的主题和缓存文档，了解它们如何处理不可缓存的页面内容，例如购物篮摘要和显示用户名 - 但是任何缓存都应该缓存所有产品块，因此制作前端产品页面应该访问缓存而不是访问数据库。
当然，如果您有 20000 个产品（或 100,000 个？= 20,000 个已配置 + 4*20,000 个简单），那么每个页面都需要访问一次以填充您的缓存，因此您可能需要设置一个链接检查器在一夜之间运行以命中所有URL 并为每个类别和/或产品页面准备完整的页面缓存。
- 检查您的主题 .phtml 文件中是否存在可怕的
Mage::getModel(catalog/product)->load($_product->getId())
这条线会影响您的数据库困难，如果您对类别页面上的每个产品都这样做，那么它会带来麻烦。如果您的主题使用->load()，那么请与您的主题设计师讨论如何创建具有他们需要的属性的集合。但是，如果您有页面缓存，那么这不一定重要（因此我认为您的缓存不起作用）。
- 看看您的
core_url_rewrite 表
由于您拥有的所有产品，这张桌子可能很大。它可能有助于使您的简单产品不可见，并且仅使可配置项在目录和搜索中可见。检查表有多少行，截断它，然后转到 Magento 管理员并重新索引重写 - 这将重新构建表，您可以查看它是否有更少的行（Magento 似乎加倍了很多重写时间）。此外，您还将获得 Magento 中每个商店的全套重写，因此请删除您不使用的所有商店。
现在关于缓存的另一个说明。我发现core_url_rewrite 是瓶颈之一，所以我在.phtml 周围放置了一个缓存，以生成商店菜单，因为菜单没有太大变化，这样做可以节省大量数据库时间。但是，如果您已经有缓存，那么除非您的缓存无法正常工作或设置不正确，否则这将不是问题。
- 让 Varien 分析器工作
这样您就可以看到 magento 花了这么长时间。我认为您需要关闭缓存才能使其正常工作。这是useful tool for speed profiling，但存在其他免费工具，实际上您可以在没有工具的情况下使用 Varien 分析器。该工具将告诉您在页面上构建需要很长时间的内容（但如果您的缓存工作正常，那么它不会；无论页面故事要构建多长时间，因为该页面将从缓存提供这就是为什么我认为您的缓存不起作用）。
- 您说“运行良好的 MySQL 数据库 - 我可以进行查询并快速获取它们。”
但这并不是测试您的数据库是否正常工作的标准。也许您知道这一切，但您可以使用 phpmyadmin 来检查您的 my.cnf 设置是否已优化。 phpmyadmin->status->advisor 将为您提供innodb_buffer_pool 和key_buffer_size 和table_cache 的提示。不管你做什么，Magento 没有优化的索引，所以 mysql 总是有很多工作要做。您可能想查看您的 innodb 文件，就像建议的 here（和我 this is required reading too）一样，但是如果您的 ibdata1 文件和您的 innodb 日志文件不是太大并且您在慢速查询中没有任何内容日志并且您不会遭受太多锁定等待，那么使用'innodb_file_per_table' 运行可能没有优势。有人建议innodb_file_format=Barracuda，但我认为我们正在进行微调以挤出最后一毫秒。
这是truly excellent Stackoverflow Q&A about ibdata files, table optimization and innodb management。警告：我不知道为 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 和内存已用完，也许您需要更大的盒子，但如果您的整页缓存工作正常...
使用top 还会显示您的服务器是否已被入侵，并且所有 CPU 周期都被某些脚本小子的比特币矿工占用。
- 扔钱
去 M3 Extra large box，打电话给 Percona 并接受它的所有建议，获得大量 RAM 并在 ramdisk 中运行您的数据库，从 Facebook 雇用一些孩子在 HHVM 上运行 Magento，或者说“搞砸”并付钱Magento 专家托管公司为您做这一切。但是，如果您的整页缓存正常工作...
---------
无论如何，我希望你玩得开心。我喜欢让 Magento 跑得更快。有大量的旋钮需要调整，看到页面加载时间一点一点地下降是非常有益的。
哦，我认为整页缓存对缓慢的管理区域没有帮助，但是有一些模块可以让管理大型产品目录变得更加简单。