magento性能优化最佳实践(官方文档)

硬件配置

CPU

1CPU同时处理两个并发magento请求(有时4个),公式如下:

N[Cores] = (N[Expected Requests] / 2) + N [Expected Cron Processes]

内存

PHP

Magento 2 has differing PHP memory requirements, based on how your system is deployed. In general, if you are setting up a single server store and plan on using the web setup wizard, we recommend configuring PHP memory for 2G. If you are setting up a site using pipeline deployment, we recommend 2 GB on your build server and 1 GB on your web nodes.

场景和相应的PHP内存要求:
web节点只支撑前台: 256 MB
web节点支持管理页面: 1 GB
Magento 2 定时索引: >256 MB
Magento 2 编译和部署静态文件: 756 MB
Magento 2 在网页上安装或更新扩展: 2 GB
Magento 2 性能工具: >1 GB PHP RAM, >16 MB MySQL TMP_TABLE_SIZE & MAX_HEAP_TABLE_SIZE 
MYSQL

Magento 2数据库(以及任何其他数据库)对可用于存储数据和索引的内存量很敏感。 为了有效地利用MySQL数据索引,可用内存量至少应该接近存储在数据库中的数据大小的一半。

Caches缓存

如果您要部署多个Magento 2并使用Redis或Varnish作为缓存,请记住以下原则:

  • Varnish整页缓存内存失效很有效,建议将足够的内存分配给Varnish,以便将最常用的页面保存在内存中
  • session缓存是配置单独的Redis实例的理想选择。 此缓存类型的内存配置应考虑站点的购物车放弃策略以及会话应该保留在缓存中的时间
  • Redis应该有足够的内存来保存内存中的所有其他缓存以获得最佳性能。 块缓存将是确定要配置的内存量的关键因素。 块缓存相对于站点上的页面数量增加(skus的数量x商店视图的数量)
网络带宽

足够的网络带宽是Web节点,数据库,缓存/会话服务器和其他服务之间数据交换的关键要求之一。 由于Magento 2有效地利用缓存来实现高性能,因此您的系统可以与Redis等缓存服务器主动交换数据。 如果Redis位于远程服务器上,则必须在Web节点和高速缓存服务器之间提供足够的网络通道,以防止读/写操作出现瓶颈。

软件配置

推荐的软件组合

  • PHP
  • NGINX+ PHP FPM
  • MYSQL
  • VANISH
  • Elasticsearch & Elasticsearch Search Adapter

多服务器部署: session缓存redis + 一个单独的redis用于默认缓存

操作系统

Magento的操作系统配置和优化与其他高负载Web应用程序类似。 随着服务器处理的并发连接数量的增加,可以完全分配可用套接字的数量。 Linux内核支持“重用”和“回收”TCP连接的机制。 请注意,比重复使用更积极的回收可能会导致负载平衡器出现问题。要启用这些内核设置,编辑/etc/sysctl.conf

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

内核参数net.core.somaxconn控制等待连接的最大打开套接字数。 此值可以安全地增加到1024,但应该与服务器处理此数量的能力相关联。

#vi /etc/sysctl.conf
net.core.somaxconn = 1024

PHP

扩展
php-bcmath
php-cli
php-common
php-curl
php-gd
php-intl
php-mbstring
php-mcrypt
php-opcache
php-openssl
php-pdo
php-soap
php-xml
php-xsl
php-zip
PHP设置
内存

memory_limit=768MB

字节

要在PHP7上获得Magento 2的最大速度,必须激活OpCache模块并正确配置它。

opcache.memory_consumption=512MB
opcache.max_accelerated_files=60000
opcache.consistency_checks=0
opcache.validate_timestamps=0
opcache.enable_cli=1

如果您的内存较少,并且没有安装许多扩展,请使用以下设置获得类似的结果:

opcache.memory_consumption=64
opcache.max_accelerated_files=60000

WEB服务器

Magento完全支持Nginx和Apache Web服务器。 Magento在 nginx.conf.sample(Nginx)和 .htaccess.sample(Apache)文件中提供了示例推荐的配置文件。 Nginx示例包含更好性能的设置,其设计使得几乎不需要重新配置。 示例文件中定义的一些主要配置最佳实践包括:

  • 在浏览器中缓存静态内容的设置
  • PHP的内存和执行时间设置
  • 内容压缩设置

除此之外需要对web服务器的进程数进行配置:

  • Nginx worker_connections(/etc/nginx/nginx.conf)
  • Apache 2.2 MaxClients
  • Apache 2.4 MaxRequestWorkers
MYSQL

本文档未提供深入的MySQL调优说明,因为每个商店和环境都不同,但我们可以提出一些一般性建议。

  • innodb_buffer_pool_instances = 8
  • innodb_buffer_pool_size = 128MB
  • max_connections = 150
  • innodb-thread-concurrency = 0
Varnish

Magento强烈建议您使用Varnish作为商店的整页缓存服务器。 PageCache模块仍然存在于代码库中,但它应仅用于开发目的。 它不应与Varnish一起使用,或代替Varnish使用。 在Web层之前的单独服务器上安装Varnish。 它应该接受所有传入的请求并提供缓存的页面副本。 为了使Varnish能够有效地使用安全页面,可以在Varnish前面放置一个SSL终止代理。 Nginx可用于此目的。 Magento为Varnish(版本4和5)分发一个示例配置文件,其中包含所有建议的性能设置。

  • 后端运行状况检查 - 轮询Magento服务器以确定它是否及时响应。
  • Grace mode-允许您指示Varnish将对象保留在超出其生存时间(TTL)期间的缓存中,并在Magento不健康或尚未提取新内容时提供此陈旧内容。
  • Saint mode-将不健康的Magento服务器列入可配置的黑名单。 因此,使用Varnish作为负载均衡器时,不健康的后端无法提供流量。
优化资源文件性能

通常,我们建议将资源文件(图像,JS,CSS等)存储在CDN上以获得最佳性能。 如果您的站点不需要部署大量语言环境,并且您的服务器与大多数客户位于同一区域,则可以通过将文件存储在Varnish中而不是使用CDN,以较低的成本获得显着的性能提升。 要将文件存储在Varnish中,请在Magento for Varnish 5生成的default.vcl文件中添加以下VCL条目。

  • 在vcl_recv子例程中的PURGE请求的if语句结束时,添加:
# static files are cacheable. remove SSL flag and cookie

if (req.url ~ "^/(pub/)?(media|static)/.*\.(ico|html|css|js|jpg|jpeg|png|gif|tiff|bmp|mp3|ogg|svg|swf|woff|woff2|eot|ttf|otf)$") {
  unset req.http.Https;
  unset req.http./*  */;
  unset req.http.Cookie;
}

  • 在vcl_backend_response子路由中,查找为GET或HEAD请求取消设置cookie的if语句。 更新的if块应如下所示:
# validate if we need to cache it and prevent from setting cookie
# images, css and js are cacheable by default so we have to remove cookie also

if (beresp.ttl > 0s && (bereq.method == "GET" || bereq.method == "HEAD")) {
  unset beresp.http.set-cookie;
if (bereq.url !~ "\.(ico|css|js|jpg|jpeg|png|gif|tiff|bmp|gz|tgz|bz2|tbz|mp3|ogg|svg|swf|woff|woff2|eot|ttf|otf)(\?|$)") {
  set beresp.http.Pragma = "no-cache";
  set beresp.http.Expires = "-1";
  set beresp.http.Cache-Control = "no-store, no-cache, must-revalidate, max-age=0";
  }
}

每当升级站点或部署/更新资源文件时,请重新启动Varnish服务器以刷新缓存的文件。

缓存和会话服务器

Magento提供了许多选项来存储缓存和会话数据,包括Redis,Memcache,文件系统和数据库。 下面讨论其中一些选项。

单web节点

如果您计划仅使用一个Web节点来提供所有流量,则将缓存放在远程Redis服务器上是没有意义的。 相反,要么使用文件系统,要么使用本地Redis服务器。 如果要使用文件系统,请将缓存文件夹放在RAM文件系统上安装的卷上。 如果您想使用本地Redis服务器,我们强烈建议您配置Redis,以便它使用套接字进行直接连接,而不是通过HTTP交换数据。

多web节点

对于多Web节点设置,Redis是最佳选择。 由于Magento主动缓存大量数据以获得更好的性能,因此请注意Web节点和Redis服务器之间的网络通道。 您不希望通道成为请求处理的瓶颈。

参考架构

本主题描述了Magento Commerce和Magento Open Source实例的一般推荐设置,该实例使用物理托管在数据中心(非虚拟化)中的普通服务器,其中资源不与其他用户共享。 您的托管服务提供商,特别是如果它专门从事Magento高性能托管,可能会推荐一种同样或更有效的设置。

Magento参考架构图

图中每个元素的颜色表示该元素是否是Magento开源版或Magento 商业版需要的。

  • 橙色部分是开源版必须的配置
  • 灰色部分是开源版可选的配置
  • 红色部分是商业版可选的配置

image

以下部分提供了Magento参考架构图的每个部分的建议和注意事项。

Varnish
  • Varnish集群可以扩展到站点的流量
  • 根据所需的缓存页数调整实例大小
  • 在高流量站点上,使用Varnish Master确保每个Web层的缓存刷新一个请求(最多)
Web
  • 为流量和冗余启用节点扩展
  • 一个节点是master并运行cron
  • 可选的,使用专用的Admin和worker节点
Cache
  • 考虑为会话实现单独的Redis实例
  • 每个缓存可以有一个Redis实例
  • 调整实例大小以包含最大的预期缓存大小
数据库和队列
  • 高流量站点可以通过主从数据库调整数据库性能,并为订单/购物车分割数据库(在Magento Commerce中)
  • 考虑使用从数据库来启用快速恢复和数据备份
  • 低流量站点可以在DB中存储图像
搜索
  • 考虑使用Elasticsearch执行搜索
  • 根据搜索流量调整实例数
存储
  • 考虑将GFS或GlusterFS用于发布/媒体存储
  • 或者,将DB存储用于低流量站点
推荐的vanish参考架构

Magento支持几个完整的页面缓存引擎(File,Memcache,Redis,Varnish),以及通过扩展扩展的覆盖范围。 Varnish是推荐的整页缓存引擎。 Magento支持许多不同的Varnish配置。

对于不需要高可用性的站点,我们建议使用具有Nginx SSL终止的简单Varnish设置。 image

对于需要高可用性的站点,我们建议使用具有SSL终止负载均衡器的2层Varnish配置。 image

开发环境推荐配置

清除而不是禁用缓存

许多开发人员倾向于禁用其开发人员实例上的所有缓存。 我们建议仅清除缓存,而不禁用所有缓存。 当您清理缓存而不是完全禁用缓存时,Magento运行效率更高。 大多数类型的缓存在开发过程中很少失效。

如果禁用缓存,我们建议仅在开发实例中禁用页面缓存和块缓存。 请记住在测试期间启用所有缓存。

在开发模式下要避免的命令

在开发模式下,不要运行用于编译,代码生成和静态内容部署的命令。 这些命令仅用于生产模式。

bin/magento setup:di:compile
bin/magento setup:static-content:deploy

在虚拟机中的一般加载时间

页面响应时间超过2s的话需要检查配置

配置最佳实践

Magento 2提供了许多设置和工具,您可以使用它们来缩短页面上的响应时间并提供更高的吞吐量。

定时任务

Magento Open Source中的所有异步操作都是使用Linux cron命令执行的。 link

索引

索引器可以在“保存时更新”或“计划更新”模式下运行。 每当目录或其他数据发生更改时,“保存更新”模式会立即进行索引 此模式假设您的商店中的更新和浏览操作强度较低。 在高负载期间,它可能导致严重的延迟和数据不可用。 Magento建议在生产中使用更新计划模式,因为它存储有关数据更新的信息,并通过特定的cron作业按后台部分执行索引。 您可以在“系统”>“工具”>“索引管理”配置页面上单独更改每个Magento索引器的模式。

缓存

在生产环境中启动商店时,请从“系统”>“工具”>“缓存管理”页面激活所有缓存。 我们强烈建议使用Varnish,因为它是一种高效的生产环境页面缓存解决方案。

异步邮件通知

启用“异步电子邮件通知”设置会将处理结帐和订单处理电子邮件通知的流程移至后台。 要启用此功能,请转到商店>设置>配置>销售>销售电子邮件>常规设置>异步发送。 详情

异步订单数据处理

在Magento执行密集订单处理的同时,有时会在店面上进行密集销售。 您可以配置Magento以区分数据库级别上的这两种流量模式,以避免相应表中的读取和写入操作之间发生冲突。 您可以异步存储和索引订单数据。 订单被放置在临时存储中并批量移动到订单管理网格而没有任何冲突。 您可以从 Stores > Settings > Configuration > Advanced > Developer > Grid Settings > Asynchronous indexing. 激活此选项详情。

延迟库存更新

在密集销售时,Magento可以推迟与订单相关的库存更新。 这样可以最大限度地减少操作次数并加快订单处理流程。 但是,此选项存在风险,只能在商店中激活延期交货时使用,因为此选项可能导致库存数量为负数。 对于可以根据需要轻松重新填充库存的商店,此选项可以显着提高Checkout流量的性能。

客户端优化设置

要提高Magento实例的店面响应能力,请转到Admin in Default或Developer模式并更改以下设置: Stores -> Configuration -> Advanced -> Developer

  • Grid Settings -> Asynchronous indexing -> Enable
  • CSS Settings -> Minify CSS Files -> Yes
  • JavaScript Settings -> Minify JavaScript Files -> Yes
  • JavaScript Settings -> Enable JavaScript Bundling -> Yes
  • Template Settings -> Minify HTML -> Yes

数据库维护计划

我们建议为Staging和Production实例执行定期数据库备份。 由于备份操作的I / O密集型特性,您可能会遇到较慢的备份和潜在问题。 由于争用可用资源,同时为多个环境运行数据库进程可能会运行得更慢。 为了获得更好的性能,请安排备份在非高峰时间连续运行,一次运行一次。 此方法可避免I / O争用并缩短完成时间,尤其是对于较小的实例,较大的数据库等。

部署流程

Magento生产部署流程可帮助商店达到最佳性能。

部署静态内容

部署静态内容会导致Magento 2执行以下操作:

  • 分析所有静态资源
  • 执行内容的合并,最小化和捆绑
  • 读取和处理主题数据
  • 分析主题fallback
  • 将所有已处理和具体化的内容存储到特定文件夹以供进一步使用

如果未部署静态内容,Magento会即时执行所有列出的操作,从而导致响应时间显着增加。 运行以下命令以部署静态内容: bin/magento setup:static-content:deploy

预处理依赖注入指令

当您预处理并编译依赖注入(DI)指令时,Magento:

  • 读取并处理所有当前配置
  • 分析类之间的依赖关系
  • 创建自动生成的文件(包括代理,工厂等)
  • 将编译的数据和配置存储在缓存中,可以节省高达25%的请求处理时间

运行以下命令预处理和编译DI: bin/magento setup:di:compile 编译完成后,我们建议运行以下命令: composer dump-autoload -o --apcu 此命令允许Composer重建到项目文件的映射,以便加快它们的加载速度。

设置生产模式

最后,您需要将商店置于生产模式。 生产模式专门针对商店的最高性能进行了优化。 它还会取消激活所有特定于开发人员的功能。 这可以在.htaccess或nginx.conf文件中完成: SetEnv MAGE_MODE production 您还可以在一个CLI命令中部署静态内容,编译内容和设置模式:bin/magento deploy:mode:set production 该命令在后台运行,不允许您在每个特定步骤上设置其他选项。

额外的发布前操作

建议采用这些步骤,但这不是强制性的。 您可以在以生产模式启动商店之前立即执行它们。 该清单包括:

  • 重新索引数据以避免索引中存在任何不一致的数据。
  • 刷新缓存以确保缓存中没有旧的或不正确的数据。
  • 预热缓存,提前调出最常用或最关键的商店页面,因此生成并存储它们的缓存。 如果您有一个小商店,可以使用任何互联网爬虫或手动执行此操作。

高级设置

Magento 2是一款高度灵活且可扩展的产品,包含适用于各种规模商家的解决方案。 本节介绍有关配置Magento以处理大量数据,极端负载和其他企业案例的最佳实践和建议。

用Elasticsearch处理搜索

默认情况下,Magento使用MySQL进行所有搜索操作。 Magento Commerce允许您将Elasticsearch用作更优化的搜索解决方案。 使用Elasticsearch,查询处理的时间不会随着搜索结果的增长而改变(与MySQL的方式相同)。 当您的商店负载增加时,Elasticsearch可以提供扩展机会。 要使用Elasticsearch运行Magento,您不需要任何特定配置 - 只需安装服务器并在Magento admin中选择Elasticsearch搜索引擎选项即可。

校准索引性能

处理大量数据时,重新编制索引可能会成为一个问题。 Magento团队选择了最多的索引并启用了批量索引,这允许您设置每次迭代时要处理的数据的一部分。 这样,用户可以根据数据库中数据的类型和大小调整批量大小。 要管理此设置,请编辑相应模块的di.xml文件中的batchRowsCount参数。 以下索引支持此功能:

  • Category Product Index (Catalog Module)
  • Price Index (Catalog Module)
  • EAV Index (Catalog Module)
  • Stock Index (CatalogInventory Module)

您可以通过调整索引批处理大小变量来调整索引器性能。 这可以控制索引器一次处理多少个实体。 在某些情况下,我们看到索引时间显着减少。

例如,如果您正在运行类似于B2B Medium的配置文件,则可以在app / code / Magento / catalog / etc / di.xml中覆盖配置值batchRowsCount,并覆盖默认值5000到1000.这会减少完整索引 使用默认MySQL配置从4小时到2小时的时间。

设置Redis

有时,一个Redis实例不足以为传入的请求提供服务。 我们可以推荐几种解决方案来解决这种情况。

首先,Magento允许您为每种缓存类型配置单独的缓存存储。 这允许您安装与Magento中注册的缓存类型数一样多的单独Redis实例。 实际上,您可能希望Redis实例用于最常用的缓存,例如配置,布局和块。

另一种解决方案是将配置缓存放在文件系统上,并将其他缓存移动到Redis服务器。 使用此解决方案,您需要一个单独的工具,用于在所有Web节点上集中失效配置缓存。

您还可以使用Redis群集,该群集使用自动增加的节点数执行并行读/写操作。 Magento不提供此案例的配置,但可以使用次要自定义启动它。

设置RabbitMQ

Magento使用此服务执行大量异步操作,包括B2B目录操作和异步库存更新。 用于向作业服务器添加更多作业的所有接口都随产品一起分发,并可用于第三方扩展范围内的自定义异步逻辑实现。 与任何其他集成一样,Magento为RabbitMQ提供了一个示例配置文件,其中包含所有建议的设置,并且完全可以用于生产。

拆分数据库

Magento商业版功能

提供媒体内容

Magento没有提供任何特定的集成来提供和提供媒体内容。 所有常用方法都可以在Magento中一起使用。

提供媒体内容的最简单方法是在Varnish服务器上提供和缓存它。 此方法假定用于存储媒体内容的共享文件系统或指向Varnish的专用服务器。

配置日志存储

日志的存储及其对其他磁盘操作的影响会影响Web节点的可用性,尤其是在高负载情况下。 如果您不需要,我们建议您尽量减少日志记录。 您还可以配置日志记录,以便在具有高访问速度的单独存储系统上进行写入。 请注意,访问日志存储的任何瓶颈都可能直接影响对作为其流程的一部分记录写入或读取操作的传入请求的处理。

高级JavaScript bundling

捆绑JavaScript模块以获得更好的性能是减少两件事:

  • 服务器请求的数量。
  • 这些服务器请求的大小。

开箱即用,Magento提供了两种减少服务器请求数量的方法:合并和捆绑。 默认情况下,这些设置处于关闭状态 您可以在商店>设置>配置>高级>开发人员> JavaScript设置中的Magento管理UI中打开它们,也可以从命令行打开它们。

基础捆绑

php -f bin/magento config:set dev/js/enable_js_bundling 1 这是一种本机Magento机制,它结合了系统中存在的所有文件,并将它们分配到相同大小的捆绑包中

但浏览器仍然加载所有JavaScript包,而不仅仅是所需的。

基本合并

php -f bin/magento config:set dev/js/merge_files 1 此命令将所有同步JavaScript文件合并到一个文件中。 在没有启用捆绑的情况下启用合并也没有用,因为Magento使用RequireJS。 如果您不启用捆绑,Magento只会合并RequireJS及其配置。 当您启用捆绑和合并时,Magento会创建一个JavaScript文件:

真实的渲染时间

以上的捆绑和合并加载时间在开发环境中看起来很棒。 但在现实世界中,许多事情可能会降低渲染速度:连接速度慢,连接阈值大,网络有限。 此外,移动设备的渲染速度不如桌面。

高级捆绑

JavaScript捆绑的目标是减少浏览器中加载的每个页面所请求资产的数量和大小。 为此,我们希望构建我们的捆绑包,以便我们商店中的每个页面只需要为每个访问的页面下载一个公共捆绑包和一个特定于页面的捆绑包。

实现此目的的一种方法是按页面类型定义捆绑包。 您可以将Magento的页面分类为多种页面类型,包括类别,产品,CMS,客户,购物车和结帐。 分类为其中一种页面类型的每个页面都有一组不同的RequireJS模块依赖项。 当您按页面类型捆绑RequireJS模块时,最终只会有少量捆绑包覆盖商店中任何页面的依赖关系。

例如,您可能最终得到所有页面共有的依赖项的捆绑包,仅用于CMS的页面的捆绑包,仅用于目录的页面的捆绑包,用于仅搜索页面的另一个捆绑包以及用于Checkout页面的捆绑包。

您还可以按目的创建捆绑包:用于常见功能,产品相关功能,送货功能,结帐功能,税金和表单验证。 如何定义捆绑包取决于您和Magento商店的结构。 您可能会发现某些捆绑策略比其他策略更有效。

具体详细操作见模块化js: