采用性能生命周期的重要性

合并整个开发流程中的性能考虑因素

本文概述了性能生命周期背后的基本概念,这些概念有助于您理解需要各种利益相关者参与的活动,从而确保获得成功的实现。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Keri-Anne Lounsbury, 交付经理, IBM

Keri-Anne Lounsbury 是 IBM 软件部的交付经理。Keri-Anne 在 IT 行业拥有 15 年的丰富经验,致力于电子商务领域的研究。她的经历包括领导客户和 IBM 团队交付复杂的 WebSphere Commerce 项目,帮助客户解决关键的问题,以及为实现峰值性能而准备好站点。



Kevin Yu, 资深认证咨询 IT 专家, IBM

Kevin Yu 是一位应用程序性能专家,在 IT 行业拥有 14 年的丰富经验。Kevin 研究过应用服务器、企业商务和数据库产品。他领导过多领域的团队解决关键的客户问题,指导过许多客户在他们一年中最繁忙的在线购物期间实现了新的交易量和销售额记录。



2012 年 10 月 24 日

简介

性能是 IT 团队常常寻求咨询建议的一个领域,无论是寻求一般指导,还是解决威胁到应用程序或网站稳定性的特定关键性能问题。尽管二者都是讨论网站性能的明确、有效的原因,而不太明显的原因很可能正是 “性能” 的含义、影响它的因素、谁需要参与改进它,而且可能最重要的是,为什么它是开发流程中不可或缺的一部分。

本文概述了性能生命周期背后的重要理念,从项目管理角度和执行角度帮您准备好应对在 Web 项目开发中通常最具挑战性的、至关重要且被忽视了的元素之一。要解决的问题包括:

  • 为什么业务支持者和 IT 支持者都需要关注和理解性能基础知识?
  • “性能” 包含什么?
  • 为什么必须有一个业务计划来实现高性能网站?
  • 什么是性能生命周期?
  • 业务和 IT 团队应如何协作来构建有效的性能策略?

性能的重要性

性能直接影响着业务目标,反之亦然。例如,几乎所有零售商的当务之急都是提升收入和获取利润。为此,一个零售业务目标可能是通过吸引人的且独特的客户体验来保持竞争优势。这可以包括以一种有意义的方式向消费者提供产品和服务,鼓励他们购买和获取更多回报,或者提供一种可以证明商品和服务所提供的价值、并让客户与志趣相投的人交流相互的体验,所有这些旨在保持相对于只需单击鼠标即可的竞争对手的优势。

要实现这些关键的成功因素,一个基础需求是网站必须提供一种可靠的用户体验,以非常快的响应时间为购买者提供他们想要的商品。如果您认为所有这些必须以一种可盈利的方式完成,所考虑的硬件和软件投资回报与将获得的收入量之间的比例将成为一个重要指标;在性能方面,我们在容量规划方面探讨了硬件和软件的量。

那么,如果在发布站点之前或在站点上执行其他重要事件之前不考虑网站的性能,会怎么样?影响是否真的这么不利?答案是肯定的,而且很明显。下面是在开发周期中未能充分考虑性能的一些可能结果:

  • 高峰期间的网站故障。在实体店中,这类似于无法打开您商店的前门。这会导致:
    • 收入损失。
    • 消极的客户体验,这会损毁您的品牌,促使客户拜访竞争对手。
    • 潜在的法律问题和处罚。示例可能包括您无法通过一个不可靠或不可用的站点满足对子公司和合作伙伴做出的承诺,或者无法满足完成交易的时间承诺(这在金融交易中尤为重要)。
    • 客户支持组织的成本增加,因为您的呼叫中心会在在线危险期变得很繁忙。
  • 网站速度变慢,这会导致:
    • 站点被认为不可用。不可用的站点的所有消极方面都可能在这里发生。随着在线世界变得越来越快,竞争越来越激烈,用户对您的站点失去耐心的时间比您认为的要短得多。
    • 复合的性能问题。认为用户请求无响应的想法可能导致用户再试一次,这会产生沮丧的心情、创造瓶颈,还会增加处理重复交易的复杂性。
  • 比起最初预计的掩盖网站低效性的解决方案来说,添加了更多的硬件和软件的 Patchwork 解决方案
    • 尽管这可能在短期内有效,但这样一种策略的成本会抵消利润,而且可能损毁负责网站的开发和 IT 团队的声誉。
    • 此策略可能会用尽其他重要项目的资金。

然而形势并不总是这么糟糕。尽管本文的意图是明确地表明忽略性能的负面影响可能是巨大的,但本文的其余部分会提供一些想法来帮助您实现一个高性能站点,以便满足所有时段(包括业务的最重要时段)的关键业务需求。


性能的影响

应用程序性能常常等同于响应能力。因为速度是主观性的,所以它的定义因受众和组织不同而不同。如果零售公司的网站可在几秒内提供目录页面并下单,它可能认为它的网站性能很快。相反,股票交易应用程序以毫秒为单位来测量速度。作为用户,您可能会容忍花几秒时间来在线执行银行交易,但如果购物网站的速度太慢,一种可行的选择可能只是转而访问一个替代站点。

这个零售示例强调了应用程序性能的重要性以及它与公司的底线有何联系,因为繁忙的一天中的每一分钟都可能意味着重大的销售获利或损失。因此,性能不仅仅是一种用户体验的收益。它可提升站点的声誉、提升客户忠诚度,还可显著影响站点收入。最重要的是,性能不仅仅关乎优化和速度。它关系到对企业底线的贡献。

在项目之间显著不同的另一个性能方面是性能战略的执行,这可能因组织不同而不同。性能测试的想法常常被认为是添加一个测试阶段,相信只需在发布前运行性能测试即可消除性能风险。尽管这比假设性能会自然地提升或由支持团队负责要好得多,但事实是要确保一个站点将正常运行,需要的不仅仅是一些测试。测试阶段可能发现应用程序中的瓶颈,但修复可能需要一个依赖于应用程序设计和架构的基本原则的解决方案。仅在开发结束时考虑性能会导致无法按时解决问题,或者必须进行修补并继续运行。从长远来看,“权宜之计” 模式会得到变得难以管理和优化的日益复杂的应用程序。性能生命周期的关键在于考虑项目所有方面的性能,而不要将它视为一个一次性事件。


性能生命周期

传统的项目计划会给项目的大部分内容留下大量非托管的性能活动。在该计划中,性能被视为接近周期结束时的一个测试阶段,这时通常没有足够的时间和资源来实现性能目标,因为这么晚才发现的问题可能很严重,无法在快速接近的部署日期之前更正。而且,因为开发已在此阶段完成,所以解决方案常常以事后办法或替代方法的形式提供,这可能为未来的开发增加了应用程序逻辑的复杂性。在某些情况下,糟糕性能的根源可能是系统架构,这也可能无法在项目周期后期得到解决。

性能生命周期的前提是在整个项目生命周期中考虑性能。采用性能生命周期方法会将性能从一个时间点活动转移到一个与项目的开发活动并行且同等重要的跟踪中。这会提高整个项目的性能可见性,它的可交付成果也将成为项目计划的重要方面。此外,实现预定义的性能标准成为了网站或应用程序发布审批流程的一部分。关键性能指标会针对目标不断进行处理和跟踪。

性能生命周期活动

图 1 显示了性能相关活动在项目生命周期的传统设计、实现、测试和发布阶段中的位置和时间安排。

图 1. 性能生命周期概览
图 1. 性能生命周期概览

性能生命周期的每个阶段的活动包括:

  • 设计
    • 与 IT 和业务利益相关者一起审核和验证非功能性需求。
    • 协助应用程序流设计。
    • 对开发人员进行性能培训。
    • 审核专注于性能的组件设计。
    • 准备系统维护策略。
    • 识别用于监视的关键性能指标 (KPI)
  • 编码和单元测试
    • 开发人员执行的应用程序剖析(性能验证的第 1 阶段)。
    • 识别初始缓存策略。
    • 实现系统维护策略。
    • 构建性能验证环境(包括数据)
    • 最终确定性能测试计划。
    • 与业务利益相关者一起规划优先级和风险减轻措施。
    • 插装代码来跟踪 KPI。
  • 性能测试
    • 创建脚本和测试数据、验证环境等。
    • 应用多阶段测试方法。
    • 测试单一系统并进行扩展。
    • 运行耐久性测试。
    • 在此阶段结束时测试可用性。
    • 与业务利益相关者一起计划优先级和风险减轻措施。
    • 细化 KPI 监视策略。
  • 发布和发布后
    • 将调优的测试迁移到生产环境。
    • 监视生产系统并排除其故障。
    • 分析生产访问日志,建议脚本返工。
    • 对发布后修复程序的首轮性能测试。
    • 不断与业务利益相关者沟通,以了解未来计划。

性能生命周期角色

当您的项目规划采用性能生命周期时,您的资源规划也需要反映性能资源的持续参与。关键性能角色如图 2 所示。性能架构师、项目经理和产品专家常常会参与整个生命周期,在测试阶段还会增加其他测试专家和分析师。

图 2. 项目规划关键性能角色
图 2. 项目规划关键性能角色

每个关键角色的职责包括:

  • 性能架构师
    • 性能团队领导
    • 总体领导解决方案架构和设计的性能方面
    • 负责性能相关的非功能性需求
    • 领导性能验证活动
  • 项目经理
    • 总体协调性能参与活动
    • 报告结果
    • 促进问题解决
    • 将性能与整个项目的项目经理相链接
  • 性能专家:中间件性能
    • 代码剖析分析和建议
    • 分析结果、调试和调优中间件应用程序
    • 指导性能测试设计
  • 性能专家:数据库
    • SQL、数据库索引、配置等的性能分析和建议
  • 性能专家:测试和脚本
    • 开发和维护工作负载、脚本、测试数据报告
  • 性能专家:缓存
    • 缓存设计和实现

采用性能生命周期需要更改项目、资源和流程,为性能提供在整个项目中跟踪和负责的可见性水平。有了这种更改水平,成功的实现还需要对组织的性能思维进行文化变迁。而且,由于性能的优先级常常被降低,作为可交付成果和时间线的替代,所以必须有来自高管和高层领导团队的赞助和支持才能实现此目的。


采用性能生命周期

为了帮助您计划在业务中采用性能生命周期,下面给出了适用于项目的各个阶段的一个操作抽样。合并这些操作将有助于您开始将项目文化从包含性能作为结论的传统方法过渡到项目测试阶段,进而过渡到在每个项目阶段采用性能的考虑因素。

需求定义

性能优先级:

  • 为您的站点建立关键性能和业务目标,比如:
    • 在与您的站点交易时,您的用户期望或需要什么?
    • 站点在接下来的 12-24 个月内的业务和交易目标是什么?
  • 识别将对系统资源容量或利用率产生重大影响的需求。对于可能对性能产生负面影响的内容,协商以确定它们是否真的是必备的内容,或者是否可使用一种不同(或对性能加强的要求较少)的方法满足类似的目标。
  • 表 1. 需求定义示例
    不是太性能友好更好
    在单个页面上实时显示整个存储目录。根据需要以增量形式向用户显示目录数据。

在需求定义期间不考虑性能所带来的风险:

  • 引入可能具有负面的性能影响而没有太多业务收益的功能。
  • 在实现阶段增加延迟来分类和优化功能的性能。
  • 为性能和容量考虑因素的 “反应性” 方法敞开了大门,这些方法可能会从其他项目获取资源和时间,而不是一种 “前瞻性” 方法。

设计

性能优先级:

  • 设计一个能出色地平衡功能和性能考虑因素的解决方案。
  • 设计和构建性能测试环境。开始部署支持您的性能策略所需的工具。
  • 识别可能为非功能性需求带来挑战的架构限制。
  • 表 2. 设计示例
    不是太性能友好更好
    通过对一个在地理上的远程服务提供者的 Web 服务请求来检索库存信息。当远程数据发生更改时,本地缓存的库存信息会自动刷新。

在设计期间不考虑性能所带来的风险:

  • 功能更可能使用比在容量计划估算阶段预计的更高的资源利用率。
  • 应用程序性能和用户体验可能受到第三方应用程序界面的负面影响。
  • 合适的测试环境的缺乏可能影响性能测试功能,并对测试结果提出质疑。

编码和单元测试

性能优先级:

  • 度量开发环境中的业务关键型步骤的响应时间。
  • 剖析代码执行,识别针对最佳实践的模式。
  • 表 3. 编码和单元测试示例
    不是太性能友好更好
    迭代购物车中的商品来计算适用的促销。对商品列表执行单次适用促销计算。

在编码和单元测试期间不考虑性能所带来的风险:

  • 可能在开发期间的后期才发现低效且需要大量资源的代码,这常常会危及关键里程碑。
  • 问题发现得越晚,识别和分类性能问题所需的工作就会越多。随着代码越接近生产阶段,环境会变得越复杂,且通常会受到更多的变更控制,这会增加解决问题所需的工作和时间。

性能测试

性能优先级:

  • 从一个简单、通用的测试案例开始,逐渐进入更复杂的场景和环境配置。
  • 在负载扩展到预期的峰值时,度量应用程序的性能。
  • 识别和解决资源约束和应用程序瓶颈的根源。
  • 表 4. 性能测试示例
    不是根源更好
    最大 JVM 堆大小更大,因为 JVM 由于持续 6 小时的测试中的 OutOfMemory 条件而崩溃。查找通过在 OutOfMemory 崩溃后检查堆转储而识别的内存泄漏。

不执行定义良好的性能测试方法所带来的风险:

  • 由于应用程序在未在发布前进行测试的峰值负载下崩溃时所产生的严重的业务收入影响。
  • 如果将附加硬件视为性能问题的修复方法,会产生更高的部署和系统维护成本。
  • 如果性能问题未通过测试捕获,而是直接影响到了用户,则在生产环境中进行性能分类将会非常困难。

发布和发布后

性能优先级:

  • 制定并监视生产环境中的性能指标,使团队能够在用户受到影响之前主动识别和解决潜在的问题。
  • 促进营销、性能和操作团队之间的交流,以便更好地准备促销活动。
  • 使用从生产环境捕获的数据,优化对未来营销和促销活动的规划。
  • 表 5. 发布和发布后
    不是太性能友好更好
    营销团队向 200 万注册用户发送一封促销活动的电子邮件,其中使用一个搜索页面 URL 作为登录页面。登录页面是一个静态页面,在边缘上进行缓存。性能团队还测试了该活动的预期流量增长。

风险:

  • 糟糕的用户体验导致客户流失。
  • 容量低于实际需求,这降低了应用程序性能和用户体验。

上述操作是您可以在项目中开始考虑性能因素的抽样方式,以及对性能不采用生命周期方法所带来的项目风险。


结束语

您的站点的性能特征不仅仅是一个技术考虑因素,他们还是一个业务考虑因素。通过在项目实现中采用性能生命周期方法,您可平衡站点的业务目标与合适的技术实现,以承受站点的流量和压力。

采用性能生命周期的最佳示例从需求收集阶段入手,一直到在生产环境中监视实际的站点性能。设计阶段包括实现最佳实践(比如代码优化、缓存机会和最新的性能增强技术)的审核和评估。测试阶段不仅包括功能验证,还包括对峰值负载下的用户体验的验证。通过执行这些步骤,可在开发周期的早期识别问题,这可提高开发效率,并帮助最小化不必要的成本。

最后,在需要不断发展、创建新的且令人兴奋的功能来提高收入和保持竞争力的商业环境中,您的团队应在每个发布计划中都采用性能生命周期。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=842514
ArticleTitle=采用性能生命周期的重要性
publish-date=10242012