语言 Chinese, Simplified

SEO Title

Performance Tuning in Existing Hybris Platform

介绍

任何电子商务实施可持续成功的一个主要因素是集成店面，移动应用程序和Omni Chanel集成的策略。但即使考虑到上述所有因素，如果实施的电子商务表现非常差，需要5秒以上才能做出回应，这意味着公司的声誉，品牌和收入都会陷入困境。这也意味着确保完美的性能和优化客户体验对于任何电子商务实施都至关重要。

在电子商务中，一种尺寸并不适合所有人。每种商业模式和每种实施都是不同的。 SAP Hybris（客户体验）实施通常是企业数字化转型之路的第一步。它涉及集成前端，后端和任何遗留应用程序，以便为其客户提供所需的体验，无论任何渠道或设备如何。

Post Go Live - 主要KPI或非功能期望

一般来说，在hybris或任何电子商务应用程序上线后，以下是5个主要KPI，

速度与敏捷
扩展基础架构资源
实现更高级别的可用性
改善客户体验
减少数据库管理

Post go Live - 常见生产痛点

速度与敏捷
高可用性
扩展现有的基础架构资源
积分
数据库

Post Go Live - 常见的表现痛点

交易量
糟糕的系统设计 - 架构级别和代码级别
缓存设计/设置不佳
数据库性能不佳 - 数据模型问题或事务性问题
网络性能不佳
差的集成设计 - 对实时后端系统集成的谨慎。

Post go Live - 共同的性能监测领域

数据库访问监控，包括基于事务的访问
数据库连接
内存使用情况
负载分配
缓存使用情况

Post go Live - 常用性能监控工具

Hybris管理控制台（HAC）
dynaTrace可
JMX - Java管理扩展
New Relic（云基监控工具）
新的Hybris加入缓存管理

Performance Tune Up Guide - Step by Step

如果客户的生产表现非常差或没有达到客户期望的水平，并且不知道性能不佳的根本原因，那么添加或建议改变hybris景观将是一个非常糟糕的主意。添加RAM或更多应用程序核心可能会提高生产环境的性能，但无法解决问题，并且随着商业流量的增长问题将继续存在。

此审核流程的摘要是确定问题的根本原因，通过开发提出补救措施，然后最终如何将解决方案部署到生产环境中。

为了执行详细的性能审核，我们需要将此流程拆分为以下活动：

要求收集工作坊
代码审查
监视运行时行为
电子商务平台的非功能测试
控制台日志分析
记忆分析
缓存分析
线程分析
JDBC分析

负载测试
压力测试
DataHub（TBD）

1.要求收集工作坊

该研讨会有以下目标：

利益相关者和团队结构审核
了解当前的项目状态和时间表
了解现有或实施的业务流程，并定义或了解定义性能目标的KPI。例如，搜索产品的时间，检查购物车的时间等。
了解当前生产问题的列表
验证和评估设计决策（使用技术规格查看用户故事）

2.代码审查

本次审核的目的是验证客户开发的自定义代码库，并确保其符合SAP Hybris和Java Code实现的最佳实践和模式。此评价还评估了Hybris库的适当用法，以确保自定义的可维护性和可升级性。请注意，这是源代码审查，而不是完整的解决方案架构审查。本文重点介绍静态分析工具和所提供源代码的可视化分析。

代码审核流程包括以下主题：

项目设置审核
静态代码分析
手动/可视源代码审查
数据模型验证/审核
后台配置审查
自动化测试评审
DataHub Design Review

在本次审查的范围内，我们使用SonarQube作为代码分析工具。 SonarQube使用静态规则来识别代码中的潜在问题。 Hybris提供内置的“声纳”Ant目标，以最小的附加配置运行声纳对抗Hybris扩展。

FindBugs（http://findbugs.sourceforge.net）也是一个使用静态分析来查找Java代码中的错误的程序，PMD（http://pmd.sourceforge.net）是一个使用静态规则来识别潜力的工具Java代码中的问题。这两个工具以及手动可视化分析都用于分析自定义代码库。

例如：应尽可能通过使用继承和/或实用程序类来最小化自定义代码的复制。这将导致更清晰，更可重用的代码库。并非所有重复都需要解决。代表业务逻辑并且有可能在未来发生变化的重复代码应该优先考虑。如果将来业务逻辑发生变化，则必须更新每个重复的代码块，否则将引入错误。因此，重复代码更难以维护，因为更新多个重复代码块比更新单个共享代码块需要更多努力。

软件层的标准SAP Hybris Commerce加速器设计具有清晰的关注点分离。关注点的分离非常重要，这样可以独立地增强和维护各个层，而无需了解其他层的所有细节。

重要的是要尊重这些层的分离。例如，我们不应直接从控制器访问服务或DAO;相反，他们应该调用Façade层。此代码审查还将详细审查此特定问题。

3.监控运行时行为

众所周知，我们可以使用Hybris管理控制台来监视已安装的Hybris Commerce实例的运行时行为，例如内存，CPU负载和线程概述。

同时，由于Hybris Commerce是用Java实现的，因此有另一种方法可以在JMX的帮助下实现相同的要求。

1）Java Management Extensions（JMX）是用于监视功能的Java规范。 JMX定义了托管bean（简称MBean）。 MBean是Java对象，它暴露一些指标（例如内存使用）并实现某些功能（例如刷新缓存）。

2）找到Hybris实例的JMX Remote Listener的端口号。

在我的示例中，在控制台中显示的Hybris启动日志中观察到9003。

将jmxremote.password.template复制到jmxremote.password，
并删除monitorRole和controlRole前面的＃以使两者都生效。完成后，此文件的内容如下所示：

在<JDK安装文件夹> / bin中启动jconsole.exe：
连接后，我们可以使用jconsole GUI来监控运行时行为。

我们还可以使用jconsole（JDK提供的内置工具）通过JVM客户端（如VisualVM）监控Hybris Commerce运行时行为（例如内存使用情况和CPU使用情况）。

1）打开<< HYBRIS_HOME >> / conf / local.properties并确保将以下属性添加为tomcat.generaloptions的一部分。

sun.management.jmxremote.port = 50055 -
sun.management.jmxremote.authenticate = false -
sun.management.jmxremote.ssl = false -
2）默认JVM参数不是运行大型应用程序的最佳选择。因此，应调整参数（例如，存储器和GC）以获得应用的最佳性能。

在<< HYBRIS_HOME >>下创建文件夹崩溃

打开<< HYBRIS_HOME >> / conf / local.properties并将变量java.mem替换为java.mem = 6G

打开<< HYBRIS_HOME >> / conf / local.properties用以下数据替换tomcat.generaloptions

generaloptions = -Xmx6G -Xms6G -XX：MaxPermSize = 1G -XX：NewRatio = 1 -
XX：SurvivorRatio = 12 -XX：+ UseParallelGC -XX：+ UseParallelOldGC -
XX：ParallelGCThreads = 8 -XX：+ HeapDumpOnOutOfMemoryError -
XX：HeapDumpPath = / app / hybris / crash / hybris_java.hprof -
Xloggc：/app/hybris/crash/hybris_gc.log -XX：+ PrintGCDetails -XX：+ PrintGCTimeStamps -
XX：+ PrintGCDateStamps -XX：+ PrintHeapAtGC -ea -
sun.management.jmxremote.port = 50055 -
sun.management.jmxremote.authenticate = false -
sun.management.jmxremote.ssl = false -
tanukisoftware.wrapper.WrapperManager.mbean = true -
endorsed.dirs =“％CATALINA_HOME％/ lib / endorsed” -
base =％CATALINA_BASE％-Dcatalina.home =％CATALINA_HOME％ -
encoding = UTF-8 -Dlog4j.configuration = log4j_init_tomcat.properties -
util.logging.config.file = jdk_logging.properties -
io.tmpdir =“$ {HYBRIS_TEMP_DIR}”$ {jvm.crashHack}
3）相应地更改XX：HeapDumpPath和-Xloggc路径

将所需的负载应用于系统 - Apache JMeter可用于将请求加载到系统。
在将负载应用于系统时，使用VisualVM监视CPU，内存和线程等系统资源
根据上述测试结果更改内存参数和GC参数。
如果我们为应用程序提供的内存太少，它将耗尽内存。 JVM将无法以您的应用程序所需的速率释放内存空间。在这种情况下，JVM将抛出OutOfMemoryError并完全关闭

4.电子商务平台的非功能性测试

一般而言，任何电子商务网站的效果取决于以下因素：

吞吐量
- 每秒请求
- 每分钟交易次数
- 每次点击执行
响应时间
- 任务的持续时间
- 每次点击秒数
- 页面加载
- DNS查找
- 点击和查看页面之间的时间长度

电子商务系统的非功能测试类型

A) 浏览器兼容性

缺乏对早期浏览器的支持
浏览器特定扩展
浏览器测试应涵盖主要平台（Linux，Windows，Mac等）

B)页面显示

页面显示不正确
运行时错误消息
页面下载时间不佳
死超链接，插件依赖，字体大小等

C。会话管理

会话到期
会话存储

d。可用性

非直观的设计
网站导航不佳
目录导航
缺乏帮助支持
即内容分析
误导，冒犯和诉讼内容
版税免费图像和版权侵权
个性化功能
可用性24/7

F。备份和恢复

恢复失败或失败
备份失败
容错

G。订单处理和采购

购物车功能
订单处理
交付过程
订单跟踪
交易诚信
吞吐量
审计

H。国际化

语言支持
语言显示
文化敏感性
区域会计

I。集成

数据接口格式
接口频率和激活
更新
接口容量
综合性能

H 日志和安全

登录功能
渗透和访问控制
信息传输不安全
网络攻击
计算机病毒
数字签名

5.控制台日志分析

启动hybris 6.0后，Hybris管理控制台（HAC）的架构也发生了变化。因此，日志记录配置功能变得非常有限。例如，在以前的版本中，我们能够为系统中定义的任何bean更改日志级别（如DEBUG而不是INFO）。这是一个很长的清单，成千上万的项目。出于对我来说仍然神秘的原因，在hybris 6.0 / 6.1中，HAC仅显示根记录器，编号为14项。要对其他类进行更改，开发人员需要更改配置文件并重新启动服务器。

Hybris使用在hybris中配置不同的Apache Log4j 2日志框架。仅在重新启动服务器时才应用日志记录配置中的任何更改。

例如，根据文档，如果要使用logLevel = WARN打开de.hybris.platform.jalo.flexiblesearch.FlexibleSearch的登录，则需要将以下片段添加到配置文件中（此示例适用于属性配置文件）：

log4j2.logger.hmc.name = de.hybris.platform.jalo.flexiblesearch.Flex

log4j2.logger.hmc.level =警告

log4j2.logger.hmc.appenderRef.stdout.ref = STDOUT

当hybris发生错误时，控制台日志文件对于分析根本原因非常有用。有两种方法可以获取hybris控制台日志文件。

首先，直接在YOUR_PATH \ hybris \ log \ tomcat目录中获取控制台日志文件。

第二，下载HAC中的support.zip文件。

请注意，support.zip文件将在all-items-xml文件夹，advanced.properties文件，extensions.xml文件，local.properties文件，localextensions.xml文件，项目中包含扩展中的all-item-xml文件。 all-properties-extensions文件夹中的属性文件。如果您在这些文件中有凭据信息，请将其删除。

6.内存分析

Java内存模型 - 或垃圾收集器（GC） - 解决了许多内存问题。只有在负载测试期间系统内存不足时才需要进行内存分析。推送的缓存大小越高，所需的内存就越多。通常在这些情况下添加内存，因为java现在可以处理与底层操作系统一样多的内存。记忆分析是识别所有这些问题及其根本原因的艺术。

但是，如果系统内存不足并且不是大缓存的结果，则可能发生泄漏。在这种情况下，增加更多内存只是一个昂贵的创可贴。有许多免费工具可用于分析内存转储，jmap命令可用于获取内存转储以进行分析。

内存分析仪表板打开并显示内存使用趋势。内存泄漏问题模式显示内存需求不断增长。监视内存时，请注意GC行为。高GC可能导致高CPU利用率和慢响应时间。

内存增加有两个原因：GC内存设置错误或应用程序问题。应用程序问题是内存泄漏或其他几个内存问题之一。

如果内存一直很高，使用GC但没有OutOfMemory错误，请分析恒定的高内存使用率。确定GC如何影响您的响应时间。如果内存增加并且出现内存不足错误，请尝试查明内存泄漏。

如果内存缓慢增加，并且GC减少了内存，但它再次增加，请检查GC /内存设置。它们可能不正确。

如果您有许多GC和易失性内存，但GC设置正确，则您的事务可能会消耗太多内存。分析事务内存使用情况。

7.缓存分析

缓存分析对于高性能和可伸缩的Web应用程序至关重要。 hybris提供了不同的缓存机制OOTB：

实体缓存（推车，产品，客户等）
查询缓存（数据库）
缓存是解决方案的关键部分，在定义解决方案的整体组件和层时应予以考虑。这些是处理hybris缓存时的基本假设：

缓存应该在请求处理中尽早发生：
如果请求可以由Web服务器处理，则优先使用此请求将请求传递给Hybris Commerce节点。
如果可以在DTO层缓存数据 - 除了实体和查询区域缓存层中的缓存之外，建议使用此方法。
缓存通常是性能和数据新鲜度之间的权衡。
在查看性能问题/高峰期时，请考虑可以在解决方案中更长时间或更早地缓存哪些数据集以提供更高的可伸缩性。
旨在将缓存的管理集中在一个地方（通常是Hybris Commerce节点）：
对于复杂的解决方案，信息的缓存可以在许多层中发生，例如Hybris Commerce节点，Web服务器，HTTP缓存，CDN层等。
远程层（Web服务器/ HTTP缓存/ CDN层）中的缓存逻辑应该尽可能简单和愚蠢。
在电子商务解决方案中，重要的是要有一种管理各层缓存的方法以及每层中保存的内容。

SAP Hybris Expert Services开发了一个解决方案附加组件，可以在一个地方轻松管理缓存，跨越HTTP层，如Varnish，CDN和浏览器。有关此添加的更多详细信息，请访问以下URL。

https://wiki.hybris.com/display/hybrisALF/Solution+Add-Ons

应在此处注明自定义创建的缓存，特别是已达到最大大小的任何缓存。自定义缓存往往具有较低的命中率，因为它们通常封装更多业务逻辑，而不是低级，开箱即用的缓存。如果缓存最大化，则命中率才真正显着，因为缓存大小限制现在会降低命中率。

8.线程分析

Web服务器使用数十到数百个线程来处理大量并发用户。如果两个或多个线程使用相同的资源，则线程之间的争用是不可避免的，并且有时会发生死锁。

线程争用是一个线程正在等待另一个线程持有的锁定被提升的状态。不同的线程经常访问Web应用程序上的共享资源。例如，要记录日志，尝试记录日志的线程必须获取锁并访问共享资源。

死锁是一种特殊类型的线程争用，其中两个或多个线程正在等待其他线程完成其任务以完成自己的任务。

线程争用可能会产生不同的问题。要分析这些问题，我们需要使用线程转储。

线程转储提供所有JVM / CLR线程的快照。它们是查找死锁，空闲或繁忙线程池，线程泄漏等的强大方法。该过程涉及在指定时间间隔内的峰值负载期间进行线程转储，例如在加载期间的5分钟内每隔10秒在每个SAP hybris应用程序服务器上执行一次线程转储。重要的是，在服务器完全被敲除并且没有响应之后不会进行线程转储，因为到那时，导致问题的任何问题都已经过去了。

与JVM转储相比，线程转储有许多优点：

CPU时间信息可用。
可以比较多个线程转储。
您可以按重要标准对线程进行分组。
您可以搜索涉及特定线程的PurePath。
要执行线程转储，不必在控制台中启动VM或重定向输出。
线程转储可以自动触发。
可以持久保存，搜索和分组线程转储。您可以安排线程转储。例如，您可能会在诊断系统上的负载较低时触发线程转储，以确保没有线程泄漏，或者将不同线程的CPU使用率与先前创建的线程转储进行比较。

改进线程转储的步骤

根据系统性能修改线程参数。

打开<< HYBRIS_HOME >> / bin / platform / project.properties并替换以下属性值。

acceptcount = 150
maxthreads = 300
相应地更改计数。打开<< HYBRIS_HOME >> / config / tomcat / conf / server.xml并替换以下内容

旧

<Connector port =“$ {tomcat.http.port}”
maxHttpHeaderSize =” 8192“
maxThreads =” $ {} tomcat.maxthreads”
协议=” org.apache.coyote.http11.Http11Protocol”
执行人=” hybrisExecutor”
enableLookups =”假”
acceptCount =” 150“
connectionTimeout =” 20000“
的URIEncoding =” UTF-8“
disableUploadTimeout =“true”/>
相应地更改acceptCount =“150”
线程转储是在给定时间拍摄的快照，它提供了所有已创建的Java线程的完整列表。可以分析线程转储以确定瓶颈或阻塞线程。可以使用不同的工具来分析线程转储，例如Samurai和IBM用于Java的线程和监视器转储分析器。

可以从管理控制台生成线程转储

监控àThread转储

9. JDBC分析

由于查询运行缓慢，应用程序有时会非常慢。使用JDBC日志记录分析运行较慢的查询并在需要的地方创建索引可以显着提高性能。

监控àDatabaseàJDBC日志记录

单击开始记录，然后单击特定时间后停止记录。

单击JDBC日志分析分析以查找有关所执行查询的详细信息。

10.负载测试

负载测试可确定店面在实际负载条件下的性能。此测试有助于确定多个用户同时访问应用程序时应用程序的行为方式。负载测试是模拟任何应用程序或网站上的实际用户负载的过程。它检查应用程序在正常和高负载期间的行为方式。

负载测试目标
在将应用程序推向市场或生产之前，加载测试会识别以下问题：

每笔交易的响应时间
各种负载下系统组件的性能
不同负载下数据库组件的性能
客户端和服务器之间的网络延迟
Web服务器，应用服务器，数据库服务器等服务器配置问题
硬件限制问题，如CPU最大化，内存限制，网络瓶颈等。
负载测试将确定是否需要对系统进行微调，或者需要修改硬件和软件以提高性能。
负载测试的先决条件
负载测试的主要指标是响应时间。在开始负载测试之前，您必须确定：

是否已经测量和比较响应时间 - 定量
响应时间是否适用于业务流程 - 相关
响应时间是否合理 - 现实
响应时间是否可实现 - 可实现
使用工具或秒表是否可以测量响应时间 - 可衡量
负载测试过程
负载测试过程可简要描述如下 -

为负载测试创建专用的测试环境
确定以下内容
负载测试场景
确定应用程序的负载测试事务
为每笔交易准备数据
需要预测访问系统的用户数量
确定连接速度。某些用户可能通过租用线路连接，而其他用户可能使用拨号
确定用户使用的不同浏览器和操作系统
配置所有服务器，如Web，应用程序和数据库服务器
测试场景执行和监视。收集各种指标
分析结果。提出建议
微调系统
重新测试
负载测试工具
在企业级负载测试方面，以及为敏捷和DevOps设计的所有以下工具都非常有名。它们都可以与持续交付管道集成：

NeoLoad
的loadView
加载亚军
网络负载

11.压力测试

压力测试将服务器超出容量限制，以查看内容和传递如何受到影响。有时，如果重负载测试遇到导致站点性能下降或失败的某些瓶颈，则可能会成为压力测试。压力测试用于测试系统的稳定性和可靠性。它甚至可以测试超出正常操作点的范围，并评估系统在这些极端条件下的工作方式。进行压力测试以确保系统在紧急情况下不会崩溃。它还检查系统是否在极端条件下显示有效的错误管理。

压力测试的目标

压力测试的目标是分析失败后系统的行为。为使压力测试成功，系统应在极端条件下显示相应的错误消息。
为了进行压力测试，有时可能会使用大量数据集，这些数据集可能会在压力测试期间丢失。在进行压力测试时，测试人员不应丢失此安全相关数据。
压力测试的主要目的是确保系统在故障后恢复，这称为可恢复性。

压力测试指标

度量标准有助于评估系统的性能，并且通常在压力测试结束时进行研究。常用的指标是：

1）测量可扩展性和性能
每秒页数：测量已请求的页数/秒
吞吐量：基本度量标准 - 响应数据大小/秒
轮次：计划测试方案的次数与客户端执行的次数
2）应用程序响应
命中时间：检索图像或页面的平均时间
到第一个字节的时间：返回数据或信息的第一个字节所花费的时间
页面时间：检索页面中所有信息所用的时间
3）失败
连接失败：客户端拒绝的连接失败次数（弱信号）
轮次失败：失败的轮次数
压力测试工具
市场上有以下所有工具可用于测试Web和移动应用程序。这些工具可以模拟数千名用户，以评估负载下的应用程序性能并分析响应时间。它还支持云集成 - 性能，负载和压力测试。它易于使用，具有成本效益，并提供良好的可扩展性：

加载亚军
JMeter的
压力测试仪
Neo Load

原文：http://hybrisdeepdive.com/index.php/2018/08/10/performance-tuning-in-existing-hybris-platform/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】