关键绩效指标和目标量度

组织使用关键绩效指标(KPI)来评估他们在实现目标方面的成功情况。 这些指标是可衡量的价值,可用于说明实现具体目标的实效。

这些指标可以是:

  • 商业:

    • 用于衡量关键业务目标。
    • 选择适合您的业务/方案的KPI,并清楚地定义它们是什么、如何衡量、如何使用以及由谁使用它们,这一点很重要。
  • 性能:

    • 定义如何衡量系统性能。
    • 一些示例包括页面加载时间、服务器响应时间和数据库查询性能。

部分(但不是全部)指标可以基于您识别和定义的目标指标。

目标量度

量度用于定义网站质量的量化度量。 它们基本上是您要实现的绩效目标的定义,可用于定义您的KPI(关键绩效指标)

可以定义许多量度,但您定义的量度通常涵盖性能和并发性的目标。 特别是难以量化,且往往易于​ 情绪化 ​评估的因素:

  • “网站​ 太慢 ​今天” — 慢于 ​何时符合条件?

  • “当我的同事登录时,所有​ 都会暂停” — 系统可支持多少并发用户?

  • “当我搜索时,系统​ 陷入停止 ” — 哪些搜索请求正在影响系统?

  • “下载文件需要​ 时间” — 可接受的下载时间是多少(在正常网络条件下)?

目标量度是在项目开始时定义的,用于:

  • 指示您可以提供的网站的预期维度
  • 指明要达到的最低质量
  • 定义如何衡量这些因素
  • 用作关键绩效指标的基础

与往常一样,在定义目标量度时必须谨慎:

  • 如果设置得过高,则可能无法实现
  • 如果设置过低,可能不会突出显示波动
  • 确保可反复且一致地衡量指标
  • 在衡量的不同因素之间提供平衡
  • 某些量度与测试环境相关,但某些量度应反映真实情景,因为它们必须在生产网站上测量并可重现
  • 根据量度对网站的重要性排列量度的优先级
  • 将度量限制为可以监视的集

在项目开发过程中,可以相应地更新和调整这些指标。 成功实施项目后,它们可用于帮助您控制安装并监控/维护日常操作所需的服务级别。

正确使用这些量度可以提供一个有用的工具;不负责任地使用这些量度可能会浪费时间。 与往常一样,了解您正在衡量的内容、如何衡量的内容及其原因。

NOTE
本节讨论基本原则和需要考虑的问题。 每个安装各不相同,因此要测量的实际值往往会有所不同。

一切都取决于您的项目设计

所有测量的量度都受项目设计的影响。 相反,许多问题最好通过设计更改来解决。

因此,在决定您的设计之前​ 定义您的目标指标。 这样做使您能够根据这些因素优化设计。 在项目开发后,对基本设计原则充满挑战。

在为网站创建结构时,请遵循为AEM网站推荐的结构。 确保您了解以下问题和/或原则:

  • 如何构建网站内容。
  • 模板和组件的工作方式。
  • 缓存的工作原理是什么?
  • 个性化内容的影响。
  • 搜索功能的工作原理。
  • 如何使用CSS和相关技术创建紧凑的非冗余HTML代码。

如果您觉得您的设计不遵循这些准则,或者您不确定某些影响,请澄清这些问题。 请在开始编程阶段或填写内容之前执行此操作。

基础架构

要定义或评估基础架构,它有助于定义目标值,例如:

  • 访客数/天;平均值和峰值
  • 点击量/日;平均值和峰值
  • 可用的网页数量
  • web内容量

根据您的情况以及网站的战略意义,定义基础架构可以帮助您评估和选择基础架构:

  • 服务器数
  • AEM实例数(创作和发布)

性能

有几个性能因素可供评估:

  • 单个页面的响应时间,包括:

    • 创作环境的响应时间
    • 发布环境的响应时间
  • 搜索请求的响应时间

可以通过性能优化读取此部分,该部分扩展了实际测量性能的技术详细信息。

单个页面的响应时间

关键问题是网站响应访客请求所用的时间。

尽管该值因每个请求而异,但可以定义平均目标值。 一旦证实该值既可实现,又可维护,就可使用它来监控网站的性能,并指示潜在问题的发展

创作环境和发布环境中的不同目标

您针对的响应时间在创作环境和发布环境中有所不同,反映了目标受众的情况:

  • 创作环境

    此环境由输入和更新内容的作者使用,因此它必须:

    • 适合在更新内容页面和这些页面上的单个元素时生成大量请求的少数用户
    • 尽可能快地最大限度地提高将您的内容放到网站上的工作效率
  • Publish环境

    此环境包含可供用户使用的内容:

    • 速度仍然至关重要,但通常比创作环境慢

    • 通常采用其他性能增强机制:

      • 内容已缓存
      • 应用负载平衡

设置目标响应时间

如何确定可实现的(平均)响应时间? 问题的答案往往与经验有关:

  • 网站体验
  • AEM使用体验
  • 识别具有高于平均响应时间的复杂页面(如果可能,应单独优化这些页面)

但是,在受控情况下,可以应用以下准则:

  • 70%的页面请求应在100毫秒内响应。
  • 25%的页面请求应在100毫秒至300毫秒内响应。
  • 4%的页面请求应在300ms-500ms内响应。
  • 1%的页面请求应在500ms-1000ms内响应。
  • 任何页面的响应速度都不应小于1秒。

上述数字假定满足以下条件:

  • 在发布时测量(无创作环境和/或CFC开销)
  • 在服务器上测量(无网络开销)
  • 未缓存(无AEM-output缓存,无Dispatcher缓存)
  • 仅适用于具有许多依赖关系的复杂项目(HTML、JS、PDF…)
  • 系统上没有其他负载

有多种机制可用于监控响应时间:

  • 使用AEM request.log监控响应时间

    请求日志是性能分析的一个良好起点。 除其他信息外,您还可以查看各个请求的响应时间。 有关详细信息,请参阅性能优化

  • 使用HTML注释监视响应时间

    HTML注释可用于在每个页面的源中包含响应时间信息:

    </body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

搜索请求

搜索请求可能会对您的网站产生重大影响,因为以下两方面均可能:

  • 实际搜索的响应时间

    • 快速搜索功能是您网站的质量目标
  • 对一般性能的影响

    • 由于搜索功能必须扫描(潜在较大的)部分内容或专门提取的索引,因此,如果不进行优化,此功能可能会影响整个系统的性能

同样,设置搜索请求的目标也是个经验问题,具体取决于:

  • AEM的体验
  • 与其他目标相比,使用搜索频率的评估
  • 您的持久性管理员
  • 您的搜索索引
  • 搜索功能的复杂性;基本搜索功能允许输入一个搜索词,比高级搜索更快,高级搜索允许用户使用AND/OR/NOT构建复杂的搜索语句。

这些搜索请求应从项目的一开始就进行规划和集成。 可用于监测的机制包括:

  • 使用AEM request.log监控搜索响应时间

    再次使用request.log监视搜索请求的响应时间;有关详细信息,请参阅性能优化

  • 用于测量搜索响应时间的编程机制

    要自定义您收集的有关搜索请求及其性能的信息,建议您在项目源代码中包含信息收集;有关更多详细信息,请参阅性能优化

并发

在创作环境和发布环境中使您的网站对某些用户和访客可用。 这些数字通常比您在测试时所使用的要多,但也会出现波动且难以预测。 为平均数量的并发用户和访客设计网站,但不考虑对性能产生负面影响。 再次使用request.log进行并发测试。 有关详细信息,请参阅性能优化

并发用户数量的目标取决于环境类型:

  • 创作环境

    • 通常可以准确估计并发用户的数量。 您可以了解总共有多少位作者,但(可能)并非所有作者同时处于活动状态。
  • Publish环境

    • 预测发布环境更具挑战性,因此您必须选择目标值。 同样,它应该基于您当前网站的经验以及您新网站的现实期望。
    • 特殊活动(例如,当您发布新的热门内容时)可能会超出预期,甚至超出功能(当某些活动的门票可供出售时,媒体有时会报道过这种情况)。

容量和卷

在讨论相关量度之前,请快速定义术语:

    • 系统处理和投放的输出量。
  • 产能

    • 系统传送卷的能力。
    • 每一步骤的容量和体积测量方式均不同,如下表所示。 要获得最佳性能,请确保容量与每一步的卷相匹配,并且容量和卷在所有步骤中共享。 例如,您可以计算客户端计算机上的导航,或将其放入缓存中,而不是在服务器上为每个请求计算导航。
  • 容量和卷

    什么/哪里
    容量
    音量
    客户
    用户计算机的计算能力。
    页面布局的复杂性。
    网络
    网络带宽。
    页面的大小(代码、图像等)。
    Dispatcher缓存
    Web服务器的服务器内存(主内存和硬盘)。
    Web服务器(主内存和硬盘)。 缓存页面的数量和大小。
    输出缓存
    AEM服务器的服务器内存(主内存和硬盘)。
    输出缓存中的页数和页大小,每页的依赖关系数。 Dispatcher缓存会降低此卷。
    Web 服务器
    Web服务器的计算能力。
    请求数。 缓存功能会降低此数量。
    模板
    Web服务器的计算能力。
    模板的复杂性。
    存储库
    存储库的性能。
    从存储库加载的页数。

其他量度

前几节详细介绍了要定义的主要量度。

根据特定要求,单独定义其他指标或考虑上述分类可能对您有用。

但是,与其尝试测量和定义网站的每个方面,不如使用一组易于使用且可靠的精确核心量度。 从本质上看,您的网站在移交给用户后会开始发生更改和演变。

安全性

安全是至关重要的,也是日益严峻的挑战。 必须 ​从项目的最初阶段开始考虑和计划。

安全核对清单详细说明了为确保您的AEM安装在部署时安全而应采取的步骤。 其他安全性方面包含在安全性(开发时)用户管理和安全性中。

并行和迭代任务

NOTE
以下各项:
  • 提供与AEM项目的​ first ​实现相关的概述。
  • 旨在作为抽象概述;有关具体阶段/里程碑/任务,请参阅项目核对清单
  • 任何时间尺度都是理论上的。

对于标准AEM项目的新实施,请考虑以下任务:

  • 从Sales流程移交。
  • 客户应用程序的实现(开发)。
  • 在客户站点(基础架构)上安装和配置基础架构(及相关流程)。
  • 创建(或迁移)内容(内容)。
  • 切换到操作(维护/支持)。
  • 跟进发行。

chlimage_1-2

对于所有方面,建议使用迭代方法:

chlimage_1-3

NOTE
要在实际的生产环境中进行调整、优化和用户培训,请将项目启动项拆分为​ 软启动项(降低可用性,多次迭代)和​ 硬启动项(完全可用性 — 实时)。
NOTE
请参阅项目核对清单以了解在项目生命周期中您应该执行(或评估)的任务示例。

每个类别需要注意以下几点:

  • 开发

    • 首先定义基本架构。

    • 使用多个迭代(冲刺)进行开发:

      • 第一个冲刺相当于第一个完整的开发周期。
      • 首次冲刺导致首次部署到测试环境。
      • 每一次冲刺都有一个可运行的结果。
      • 每个冲刺都会获得客户认可(带有反馈的结构化测试的最小值)。
    • 规划在项目期间更新可用AEM版本的可能性。

    • 规划冲刺期间的测试和优化。

    • 规划稳定和优化阶段。

    • 创建要计划用于后续版本的物料日志。

    • 规划合作伙伴参与和移交事宜。

  • 基础架构

    • 首先定义基本架构:

      • 定义性能要求。
      • 定义绩效目标(即明确定义预期)。
      • 定义硬件和基础架构体系结构,包括规模调整。
      • 定义部署。
    • 使用多个迭代;对于第一个冲刺和初始配置,准备:

      • 开发环境。
      • 开发过程。
      • 测试环境。
      • 部署过程(包括配置管理)。
    • 规划多个负载测试。

    • 规划冲刺期间的测试和优化。

    • 规划稳定和优化阶段。

    • 尽早部署到生产环境(让运营团队设置系统以获得体验)。

    • 尽早使用指定用户和定义的角色。

    • 规划培训(例如,管理员培训)。

    • 计划移交给操作。

  • 内容

    • 基本体系结构:

      • 驱动内容层次结构。
      • 帮助定义内容概念。
      • 定义MSM使用和布局。
      • 定义角色、组、工作流和权限。
    • 考虑离线页面创建是否有用。

    • 计划提前创建第一页和内容(用于测试和反馈)。

    • 规划现有内容的迁移。

    • 在重构后规划“in-sprint-migration”。

    • 规划“内容燃尽”(用于上线内容的站点地图)。