php - 解决Magento速度超过20,000种产品的最佳方法是什么

Question

我正在3个Amazon EC2实例上运行magento。其中一个设置为可直接通过管理面板访问，另外两个则位于负载均衡器后面。

事情进展顺利，直到我们导入了2万多种产品的数据为止，每种数据都是可配置的产品，其中包含约4种简单的产品（适用于不同的尺寸，颜色等）。

运行缓慢的唯一原因似乎是产品上的循环-管理员和前端目录页面都需要5到10秒钟以上才能从服务器获得响应。静态/ CMS页面加载正常。

它们都连接到运行良好的一个RDS MySQL数据库-我可以进行查询并快速将它们取回。

我们启用了所有缓存（包括全页缓存），并且启用了平面目录，但速度没有真正的变化。

magento目录是每个服务器独立的目录，除了media/目录与lsyncd保持同步。管理服务器充当主服务器，两个负载平衡的前端服务器充当从服务器。

Answer 1

让我们分解一下：


我会做的假设（请检查一下）


您正在相当强大的EC2实例上运行，例如m3.large
您正在运行APC等PHP缓存
您正在使用Magento编译器系统->工具->编译
您正在使用Apache Web服务器
“从服务器获得响应的5到10秒”是指响应时间，不包括图片以及CSS和JS下载到浏览器的时间
您具有用于产品和类别的平面表（但是，如果您的缓存正常运行，那么这不应控制速度。您还应该在没有平面表的情况下运行测试；它们并不总是更快）
您的网络服务器配置针对“保持生命”和“过期标头”的高流量进行了优化。






三重检查您的全页缓存


关于您的问题的真正奇怪的是，您说您拥有一个完整的页面缓存，但是产品前端页面在服务器将其发送到浏览器之前需要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 Admin并重新编制重写索引-这将重新构建表，您可以查看表中是否有更少的行（Magento似乎将许多重写加倍了时间）。另外，您将获得Magento中每个商店的完整重写，因此请删除所有不使用的商店。

现在再谈谈缓存。我发现core_url_rewrite是瓶颈之一，因此我在.phtml周围放置了一个缓存，该缓存生成了商店菜单，因为菜单变化不大，这样做可以节省很多数据库时间。但是，如果您已经有一个缓存，那么除非您的缓存不起作用或设置不正确，否则这不会成为问题。




使Varien Profiler工作


这样一来，您就可以了解magento花费了多长时间。我认为您需要关闭缓存才能正常工作。这是useful tool for speed profiling，但是存在其他免费工具，实际上，您可以不使用工具而使用Varien分析器。该工具将指示您需要花费较长时间在页面上进行构建（但是，如果您的缓存正常运行，那么它将不会成功；无论页面故事建立了多长时间，因为页面将从缓存中提供服务）这就是为什么我认为您的缓存不起作用的原因）。




您说“ MySQL数据库运行良好-我可以查询并迅速将其取回。”


但这不是测试数据库是否工作正常的标准。也许您知道所有这些，但是您可以使用phpmyadmin来检查my.cnf设置是否得到优化。 phpmyadmin-> status-> advisor将为您提供innodb_buffer_pool和key_buffer_size和table_cache的提示。无论您做什么，Magento都没有优化的索引，因此mysql总是有很多工作要做。您可能希望像建议的here（和I this is required reading too）一样查看您的innodb文件，但是如果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特大号盒子，给Percona打电话，听取其所有建议，获取一吨RAM并在ramdisk中运行数据库，从Facebook雇用一些孩子在HHVM上运行Magento，或说“把它拧紧”并付钱给Magento专家托管公司为您做这一切。但是，如果您的整个页面缓存正常工作...

----------

无论如何，我希望你玩得开心。我喜欢让Magento更快地运行。有大量的旋钮可以调整，看到页面加载时间一点一点地减少，这是非常有益的。

哦，我认为慢速管理区域不会因全页缓存而有所帮助，但是有些模块可以使大型产品目录的管理变得更加简单。