project b2c_performance / capacity

 

常用信息/技术网站推荐

http://wiki.cns*****.com/pages/viewpage.action?pageId=16613939
InfoQ中文网：http://www.infoq.com/cn
TechTarget：http://www.techtarget.com.cn/
ImportNew：http://www.importnew.com/
Java Dzone：http://java.dzone.com/
jaxenter：http://jaxenter.com/
GIGAOM：http://gigaom.com/
regulargeek：http://regulargeek.com/
百度技术沙龙：http://www.infoq.com/cn/zones/baidu-salon/index.html
阿里技术沙龙：http://club.alibabatech.org/
Gartner：http://www.gartner.com/technology/home.jsp
IDC：http://www.idc.com//home.jsp

 

 

 

关于B2C网站系统资源分析和容量计算

--参考《构建高性能WebSphere企业级应用》

性能测试组

文档记录
修订记录
本次修订日期：2012-04-14    下次修订日期：   
版本号    修订日期    变更概述    修订显示

1.    目 录

目录

1.    目 录    3
2.    当前的系统架构    4
3.    系统性能分析和容量规划的背景和目的    5
4.    系统容量综合分析过程及结果    6
4.1    电商应用基本拓扑    6
4.2    性能分析的一般过程    6
4.3    系统容量规划的范围    6
4.4    基于CPU容量规划的理论模型    6

2.    当前的系统架构
（略）
3.    系统性能分析和容量规划的背景和目的
本文仅以某B2C网站现有生产系统架构为背景，结合未来网站可能需要进行多次扩容或横纵向拓展为契机，针对网站性能测试组WebSphere系统规划分析工作作简要概述和整理。
4.    系统容量综合分析过程及结果
4.1    电商应用基本拓扑
在J2EE规范下，WebSphere分布式应用多层模型在逻辑上由4部分组成，如图所示：

The topology of the network may be ring, star or bus.

系统的拓扑结构选择与很多因素有关(可扩展性、可靠性、可维护性、安全性等)。在B2C项目应用中，网站系统应用拓扑已在2章节有较好体现，它遵循了J2EE规范。一个良好的系统架构随着业务的发展而循序渐进，通过不断优化不断突破直至趋于完美的过程。
4.2    性能规划的一般过程
4.2.1    理解应用环境
在B2C应用中，客户最常进行的业务是浏览商品(包括搜索商品)，它远远大于购物车的操作。而客户购物的复杂性不太高。因此，系统的性能瓶颈可能在Web 服务器和应用服务器端。对此，可以考虑使用动态高速缓存提高应用服务器的性能，使用代理服务器降低Web服务器的负载等。
B2B应用与B2C应用不同，客户进行浏览商品操作的频率低很多(大部分客户都有明确的购买目标)，购物操作很多而且非常复杂(涉及非常复杂的合同和定价处理逻辑)。因此，可以重点考虑优化数据库设计以提高数据库服务器的性能，优化应用服务器的业务逻辑操作代码等。
此外还要考虑用户的业务增长情况。比如,客户第一期的业务是B2C应用,但是第二期还希望增加B2B应用等。系统设计也要考虑满足这些未来的业务需求。
4.2.2    系统负载分析
基于WebSphere应用性能规划的第二步是负载分析，若理解应用环境为定性分析，则此步骤为定量分析。负载分析的重点是确定系统的各种负载指标情况，包括并发数、交易数、思考时间等。这些指标可能直接来源于用户预设要求，也可能是性能架构师与用户沟通后的信息。
负载指标的静态数值即（最大值和平均值）来源于用户现有有系统的统计数据（客户自有的IT部门）,也可能是根据传统业务量进行估计。此类沟通较好的方式应是多种渠道确定负载指标的数值，排除相互矛盾的信息。
负载的动态变化即访问模式，它包括一天的变化情况和一年的变化情况。
电商应用全年访问模式可能是在节假日有集中访问，如五一、法定黄金周等是全年的高峰。确定系统负载的访问模式不是要精确地确定具体时间的并发用户数，而是 大致的变化趋势。了解这些变化趋势有助于系统设计者在系统结构中合理分配资源，也可以帮助系统维护人员设定系统维护的时间表(如:再全天访问低谷段进行垃 圾数据清理工作)。
收集到的系统负载指标和访问模式还应当通知系统的性能测试人员。测试人员应该模拟系统的真实访问情况设计性能测试用例。系统并发数的剧烈变化也有可能造成性能问题，也需考虑测试工具模拟虚拟并发用户与真实用户的区别。
除负载指标外，应用系统所处理的各种业务对象的数量也是系统负载分析的重要内容。以电子商务系统为例：系统的产品目录中有多少产品？客户购买交易中通常会涉及多少定价合同？客户订单平均包含多少个商品？等等。
业务对象的数量首先影响的是数据库(或其他信息存储系统)的设计。对于数据量巨大的业务对象，可能需要设计专门的存储结构或建立专门的索引。业务对象的数 量也会影响应用程序中处理算法的设计，尤其是对象的处理。以电商系统为例，订单平均包含10个商品和平均包含500个商品所需要的处理算法应该不同。对于 需要处理大数据量的处理逻辑必须专门设计，否则，就可能出现严重的可扩展性问题。
总之，负载分析是需求获取阶段的重要任务。获取的系统负载信息越多越详细越好。
4.2.3    软件结构中的性能设计
需求分析阶段收集到的性能需求应当反映到系统的设计中。系统设计又可以细分为软件结构设计和硬件结构设计。
软件结构设计包括确定系统的模块结构、编程模型，以及采用的核心技术。使用数据库的系统还包括数据库结构设计。
以电子商务应用为例，系统的模块划分主要是根据业务逻辑划分：订单处理模块、产品目录和内容管理模块，以及市场营销管理模块等。系统采用的编程模型基本上是MVC模型。
软件结构设计最重要的是确定各模块之间的接口或通信方式。模块接口不仅对协调系统开发阶段个开发人员之间的工作非常重要，还会影响到最终系统运行的性能。 以电商应用为例，订单处理模块和产品目录管理数据。如果接口设计不当，在系统运行时，就有可能因为数据访问产生资源竞争和性能问题。IBM Labs开发经验用面向服务架构有助于建华模块之间的接口，减少因为i模块接口造成的性能问题。
在软件结构设计(概要设计)阶段，也需要对一些核心的提高性能的手段确立规范。比如，如果系统准备采用动态高速缓存提高性能，那么，就应该在概要设计阶段 对JSP设计模板、可缓存模板等进行定义。这样，开发人员在详细设计阶段和编码阶段才会有章可循，审阅详细设计文档或进行代码检查的时候也能有的放矢。为 详细设计文档制定模板也是常用的手段，在详细设计模板中，可以固定包含针对可扩展性的设计、缓存设计等章节，强制开发人员在详细设计阶段把性能设计放在重 要位置上。
如果在软件机构设计时决定采用一些新技术(开发团队以前没有使用过的技术)，则需要考虑进行一定原型开发，作可行性论证(Proof Of Concept).大多数情况下，采用新技术都是存在风险的。
4.2.4    硬件结构中的性能设计
对于具体实施项目而言，硬件结构设计时非常重要的环节。对于产品开发而言，硬件结构设计主要针对系统能够支持硬件平台或拓扑结构。
WebSphere应用服务器是基于Java技术的跨平台应用服务器，它屏蔽了大部分的硬件实现细节(IBM Z系列服务器上的WebSphere应用服务器可能略有不同)。对于大多数WebSphere应用程序而言，不需要考虑支持平台的问题。
    需要注意的是Web服务器和数据库服务器在不同硬件平台上所表现的性能差异对应用系统的影响。对于高性能计算硬规划应尽可能在64位CPU上进行以符合当前软件发展的潮流。
    除此之外，硬件结构设计的主要内容是拓扑结构设计(见4.1章节)和硬件配置设计(系统容量规划)。
4.3    系统容量规划的范围
对于容量规划(Capacity Planning)，不同的人可能有不同理解。本文中的容量规划是指针对特定的性能需求，制定电商系统实施的硬件配置方案，组成系统的各种硬件细节都在容 量规划的范围之内。从服务器的具体型号到各种详细配置参数(CPU的型号和数量、内存大小、硬盘速度和大小、网卡的速度和数量等)。实际上最后系统实施是 采用的具体硬件配置受很多因素制约。比如基于Intel CPU的IBM x系列服务器就不能在一台服务器中配置32个CPU。
影响系统性能的一个重要因素是服务器的硬盘大小（主要是数据库服务器的硬盘大小）。硬盘容量规划的方法相对简单一些，主要是依据系统关键业务对象的数量及 所采取的存储方式进行计算。如DB硬盘大小涉及数据表空、索引、临时表空间存储，还要考虑用户未来业务量增加的需要和最终磁盘容量的预留30%或50%等 因素。
    相对而言，磁盘容量的估算比较繁琐(需要收集的数据比较多)，但是，其原理比较简单，准确性也比较容易控制。
    除了磁盘容量之外，网络带宽也是影响WebSphere应用(尤其是Web应用)总体性能的重要因素。
4.4    基于CPU容量规划的理论模型
根据本文对容量规划的总体定义，可以将CPU容量规划定义为：针对特定的性能需求，制定系统实施案例所需要的CPU处理能力的配置方案。这里强调的是配置CPU处理能力而非具体的CPU型号。在确定CPU处理能力后，可以再处理能力类似的不同CPU型号之间做出选择。
对CPU处理能力的估算不像磁盘容量那样简单，很难直接估计系统处理一个特定交易需要“几个”CPU进行处理。CPU容量规划需要一些参考数值。最理想的 情况是，存在于需要规划的客户负载状况近似的客户配置资料，如果近似客户的配置被证明是成功的，那么，就可以向新客户推荐类似的配置。
大多数情况下，各个客户之间的负载情况差异很大，对性能指标的要求也各不近相同，很难有可供参考的类似案例。此时，通常的做法是：在严格控制的实验环境下，进行性能测试(又称容量测试)，根据测试的结果，对系统在不同负载或不同硬件配置下的性能表现做出预测。
假设通过性能测试得到的结果是：系统在硬件(CPU)配置H1上处理负载W1的时候，系统资源占用率(CPU占用率)为U1.CPU容量规划的目标是:假 设系统要处理负载W2，根据预期要使用的硬件配置H2,计算对应的CPU占用率U2，或根据期望达到的CPU占用率U2，估算需要的硬件配置H2。这里讨 论系统负载的时候，不严格区分负载指标和运行指标(吞吐率)，并且，假定系统对到达的交易请求都能及时处理，所以系统的负载指标和吞吐率指标一致。
CPU容量规划的过程就是建立负载指标、CPU处理能力和CPU占用率之间的关系的过程。直接建立三者之间的关系比较困难，所以通常采用虚拟中间结果将关系进一步分解，如图
 
    首先，建立负载中间（W2于W1）的量化关系，比如W2是W1的两倍。其次，假定在相同的硬件配置H1上运行W2，计算此时的CPU占用率U1，找到相同 硬件配置运行不同负载的关系。最后建立不同CPU处理能力的量化关系。这里假定CPU容量等于CPU处理能力和CPU占用率的乘积。即如果H2是H1的两 倍，CPU占用率U2是U1的一半，则两者的CPU容量相同：H1*U1=H2*U2。

 

end