wyq*_*syq 4 php amazon-ec2 magento amazon-web-services amazon-rds
我在3个Amazon EC2实例上运行magento.一个设置为直接访问管理面板,另外两个坐在负载平衡器后面.
事情进展顺利,直到我们用20k +产品导入我们的数据,每个产品都是可配置产品,有~4种简单产品(不同尺寸,颜色等)
唯一运行缓慢的事情似乎是循环产品的事情 - 管理员和前端目录页面需要5-10秒才能从服务器获得响应.静态/ CMS页面加载正常.
它们都连接到一个正常运行的RDS MySQL数据库 - 我可以查询并快速恢复它们.
我们启用了所有缓存(包括整页缓存)并启用了平面目录,而且速度没有真正的变化.
magento目录是每个服务器独立的,除了media/与之保持同步的目录lsyncd.管理服务器充当主服务器,两个负载平衡的前端服务器是从服务器.
让我们打破这个:
我将做出的假设(请检查它们)
关于你的问题真正奇怪的是你说你有一个完整的页面缓存,但产品前端页面需要5到10秒才能将服务器发送到浏览器.
在我看来,这意味着您的整页缓存无法正常工作.正确实现后,整页缓存将直接从Apache提供页面,而无需运行Magento app(Mage.php),这就是它如此快速的原因.这意味着在请求缓存页面时没有开销,这就是整页缓存系统应该具有小于0.25秒且有时小于0.1秒的"请求"时间的原因.
我建议您关闭整页缓存,看看它有什么不同.检查您的主题和缓存文档,了解它们如何处理不可缓存的页面内容,例如购物篮摘要和显示用户名 - 但是任何缓存都应该缓存所有产品块,因此使前端产品页面应该访问缓存而不访问数据库.
当然,如果您有20000个产品(或100,000？= 20,000个配置+ 4*20,000个简单),那么每个页面都需要访问一次以填充您的缓存,因此您可能希望设置一个隔夜运行的链接检查器以点击您的所有URL和素数每个类别和/或产品页面的完整页面缓存.
Mage::getModel(catalog/product)->load($_product->getId())
这条线很难打到你的数据库,如果你对类别页面上的每个产品都这样做,那么它会带来麻烦.如果您的主题正在使用,->load()那么请与您的主题设计师讨论如何仅使用他们需要的属性创建集合.但是如果你有一个页面缓存,那么这不一定重要(因此我认为你的缓存不起作用).
core_url_rewrite桌子由于您拥有的所有产品,这张桌子很大.它可能有助于使您的简单产品不可见,只能使配置在目录和搜索中可见.检查表有多少行,截断它,然后转到Magento Admin并重新索引重写 - 这将重新构建表,你可以看到它是否有更少的行(Magento似乎加倍了大量的重写时间).此外,您将获得Magento中每个商店的全套重写,因此请删除您未使用的任何商店.
现在关于缓存的另一个注释.我找到了core_url_rewrite一个瓶颈,所以我在它周围放了一个缓存.phtml来生成商店菜单,因为菜单没有太大变化,这样做可以节省大量的数据库时间.但是,如果您已经有缓存,那么除非您的缓存不能正常工作或设置不正确,否则这不会成为问题.
所以你可以看到长时间拍摄magento的东西.我认为你需要关闭它的工作缓存.这是一个用于速度分析的有用工具,但是存在其他免费工具,实际上您可以在没有工具的情况下使用Varien分析器.该工具将向您显示在页面上构建需要很长时间的内容(但是如果您的缓存正常工作则会赢得;无论页面构建的时间有多长,因为页面将从缓存中提供,这就是为什么我认为你的缓存不起作用).
但这不是测试您的数据库是否正常工作的测试.也许你知道这一切,但你可以使用phpmyadmin来检查你的my.cnf设置是否已经过优化.phpmyadmin-> status-> advisor会给你提示innodb_buffer_pool和key_buffer_size和table_cache.无论你做什么,Magento都没有优化的索引,所以mysql总是要做很多工作.你可能想看看你的innodb文件,就像这里建议的那样(我也需要这样阅读),但如果你的ibdata1文件和你的innodb日志文件不是太大,你在慢查询中没有任何东西日志和你没有遭受太多锁定等待然后运行可能没有优势'innodb_file_per_table'.有人建议innodb_file_format=Barracuda,但我认为我们正在进行微调以挤出最后一毫秒.
这是关于ibdata文件,表优化和innodb管理的真正优秀的Stackoverflow问答.警告:我不知道为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 =
并运行' top'来监视http守护进程和mysql服务器的内存和CPU负载 - 我有时在运行我的链接检查程序时这样做,所以我可以看到系统至少有一点负载.如果负载很小,可能你的httpd.conf和my.cnf没有设置为利用可用的CPU和内存.如果你的CPU和内存最大化,那么你可能需要更大的盒子,但如果你的整页缓存工作正常......
使用top还将显示您的服务器是否已被入侵,并且所有CPU CPU都被一些脚本小子的比特币矿工所困扰.
转到M3超大盒子,给Percona打电话并提出所有建议,获取一吨内存并在ramdisk中运行你的数据库,从Facebook雇一些孩子在HHVM上运行Magento,或者说'搞砸'然后付给Magento专家托管公司为您做到这一切.但是如果您的整页缓存正在运行......
无论如何,我希望你玩得开心.我喜欢让Magento跑得更快.有一吨旋钮可以调整,看到页面加载时间逐渐下降是非常有益的.
哦,我认为缓慢的管理区域不会受到整页缓存的帮助,但是有一些模块可以使管理大型产品目录变得更加简单.