读书笔记之LoadRunner性能测试巧匠训练营（九）

《LoadRunner性能测试巧匠训练营》第8章 .NET项目性能测试全程实践

1.项目背景及架构分析

1.1 项目背景

电商平台是一个面向宠物爱好者的平台，由于该项目之前没有做过性能测试，而过段时间网站将进行推广和促销活动，会迎来比较大的访问量，为了预估未来可能发生的性能问题，决定对本网站进行性能测试。

1.2 业务架构

本系统是在Microsoft的.NET平台上开发的，主要为了满足用户在线选购宠物的需求。整个系统完全对外开放，用户可以在该系统进行注册、登录、搜索、下单、支付等操作。
系统的主要功能模块如下。

• 注册与登录：通过输入必填的注册信息并审核通过后，方可使用该账号登录系统进行后续操作。
• 首页：展示热门的宠物简介、购买量、评论等来吸引用户。
• 宠物浏览：宠物类别浏览、宠物详细信息浏览、库存信息浏览、评论信息浏览等。
• 购物车：记录并展示用户加入购物车的宠物，这里保存的宠物并没有结算，只是有意向购买。
• 下单与支付：如果用户确定购买某宠物，需要下单并计算金额，下单成功后需要在2小时内完成支付，否则取消本次订单。
• 搜索：供用户对本系统内的宠物进行模糊查找，没有设置查询间隔时间。（一般对于这样的搜索会设定一个时间间隔，达到减小压力的目的，尤其是对于基数比较大的网站。）
• 后台管理：对系统中的宠物信息、评论等进行维护。

1.3 系统架构

一般系统架构都是典型的分层式架构的扩展，可抽象成三层，从上到下分别为表示层、业务逻辑层、数据访问层。

PP Shop具体架构分析如下。
1）表示层：它是系统的UI部分，用户通过此层与整个系统进行交互。由于业务和设计的关系，本系统并没有严格按照三层架构的思想实现，表示层和业务逻辑层之间有较高的耦合度，但也是在可接受范围内的。
2）业务逻辑层：它是整个系统的核心，负责实际业务的逻辑处理。在本系统中，业务逻辑层完成如登录、查询、添加到购物车、下单等业务逻辑。如果涉及数据库的访问，则会调用数据访问层。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。这样达到了层与层之间的松耦合。
3）数据访问层：主要负责数据库的访问。简单地说，就是实现对表的增、删、改、查。在数据访问层中，本系统很好地体现了面向接口的编程思想。将数据访问层的统一接口模块抽象出来，脱离了与具体数据库的依赖，这是非常好的做法。对MS SQL Server和Oracle数据库的操作均通过封装的统一接口模块来调用，大大提高了灵活性，而且减少了向下的依赖，对于上层的业务逻辑层而言，仅存在弱依赖关系。本系统对接的数据库是MS SQL Server，而Oracle则是为了以后和其他系统进行对接融合而预留的接口。

2.测试环境需求确认与搭建

2.1 测试环境需求确认

2.2  测试环境搭建

1）、 安装数据库MS SQL Server

2）、 安装IIS服务

3. 性能测试工具选择

在选择性能测试工具的时候，可以从如下几个方面来考虑。
1.是否符合需求
工具的最大作用就是帮助我们完成它擅长做的事情，能减少我们的劳动力，解决我们无法完成的工作。所以在工具选型的时候，是否能满足需求是非常重要的。一般而言，大部分的性能测试工具都能满足日常的性能测试需求，如果部分比较特殊的需求无法满足，就需要自主研发工具了。
对于本系统来说，选型的性能测试工具需要满足以下几点。
·支持HTTP的大并发。
·可部署在Windows上使用。
·可监控Windows、IIS、SQL Server等性能计数器。
2.购买成本
世界上没有免费的午餐，工具也一样。如果不想花费资金，那么开源的性能测试工具是最佳选择，但缺点也很明显，如易用性差、功能少、Bug多、数据统计不准确、帮助文档较少等。毕竟是免费的工具，不能要求十全十美。如果研发能力允许，那么可以对这些工具进行二次改造开发。
而商业性能测试工具恰恰避免了上述的缺点，当然需要用资金来换取。现在商业性能测试工具很多也接受定制的开发，能更好地满足特定需求，花费也是比较高的，需要根据实际情况来综合考虑。
3.学习成本
不论是买来的、开源的，还是自主研发的工具，都是给人用的，所以学习成本也是重点考虑的。如果一个工具的学习成本巨大，例如，掌握某几个功能就要一个多月，那就有点说不过去了。如果对编程能力要求较高，那么学习成本也会比较高。
一般来说，开源性能测试工具的学习成本要比商业性能测试工具高。
4.扩展成本
如果工具要长期使用，那么扩展性也必须考虑在内。试想，如果一个工具只能用一次就作废，那谁还愿意用它。自主研发和开源工具的扩展性相对好些，但商业的工具扩展性就比较差了，所以在选型的时候要衡量利弊。

4.业务建模与用例设计

4.1 业务场景分析

• 单业务场景分析：此场景测试主要是针对单个重要的、核心的业务进行性能测试。本系统的单业务场景为登录、搜索、浏览，分析如下。登录：是系统最基本的功能，也是大多数用户最常用的功能，而且下单支付操作的前提都是需要登录成功，所以登录是此次单业务场景测试的重点。搜索：在种类繁多的网站中，用户通常都会使用搜索功能来找到自己需要的商品，存在大量的查询操作，考验数据库设计以及SQL性能，因此搜索也纳入此次单业务场景测试的重点。浏览：用于展示宠物的信息，也是用户经常进行的操作，主要以查询为主，所以浏览也是此次单业务场景测试的重点。
• 组合业务场景分析：组合业务场景测试主要对典型的业务进行组合一起执行性能测试。很多人都有一个误解，就是要把所有可能组合的场景都组合起来进行性能测试。其实，应该选用重要的、常用的业务进行合理组合，以最大程度模拟真实用户的使用情况。
• 大数据量场景分析：此场景测试主要分为基于历史大数据量的性能测试、运行时大数据量的性能测试以及二者的混合。基于历史大数据量的性能测试主要是指被测试系统使用一段时间后累积了一定量的数据量，在这个数据量基础上进行性能测试，或者是针对存储、统计、查询等业务进行大数据量的性能测试，看它们是否能正常运行。此场景的关键在于分析历史数据与制造测试数据。运行时大数据量的性能测试主要是指模拟系统运行时会产生较大的数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定地运行。另外一种则是上述两者的混合，被测试系统已经累积较大数据量，一些实时产生较大数据量的业务模块能否稳定地工作。
• 稳定性场景分析：稳定性场景测试主要针对系统在长时间的压力下是否能稳定运行。稳定性场景的产生一般都会基于组合业务场景进行设计。
• 负载均衡集群场景分析：负载均衡集群场景测试主要是对负载均衡机制是否有效以及集群性能进行测试。典型的负载均衡集群架构如下图所示。负载均衡可以通过类似轮询或按比例分配等策略达到分摊分流压力的目的。一般测试的策略有两种：模拟访问请求看是否分配到两台服务器上；关闭一台服务器看访问请求是否分配到了另一台服务器上。而集群的测试更关注数据的一致性。集群的好处：避免单点故障，方便管理（可将工作负载转移给群集中的其他服务器），扩展性强。


4.2 性能需求分析与提取

一般我们遇见的性能测试需求有以下几种情景。
1）已经明确给出了性能预期指标。例如，对某业务并发20个用户，平均响应时间要≤3s，事务成功率为100%，CPU使用率≤85%，内存使用率≤85%等这样类似的指标。这种情景只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在。
2）无明确需求，需要自己挖掘或者和团队一起分析。这个也许是经常遇到的情景。对于这样的情况，可以求助运营、运维人员，根据线上监控的数据作为参考进行性能测试指标的分析与提取，这样得出的数据还是比较准确的。当然，如果连运维都没有，也没有线上的监控，那只能靠自己查找相关资料，和类似的系统做对比，然后确定性能测试需求的指标。

4.3 性能测试用例设计

用例设计无好坏，只要符合需求就可以

5.脚本开发与优化

根据3，4节完成脚本开发并进行优化

6.执行测试

场景设置和监控指标

7.性能测试分析与调优建议

7.1 服务器硬件方面
描述：
从资源利用图来看，硬件上不存在大问题。不过各业务使用的内存还是不大，而且在稳定性测试中也发现CPU存在堵塞，再考虑到以后流量的增加，还是建议扩充内存，提升CPU。
解决方案：
1）增加内存，即在服务器上插入几个内存条。一般程序都比较耗内存，是需要重点关注的。而内存方面最常出现的问题就是内存泄露、内存溢出。
2）提升CPU，即更换处理能力更好的CPU或增加核数。有关CPU性能的提升，还可以通过程序中代码的完善，参见本节后续内容。
3）可利用Windows自带的工具定期进行碎片整理。如果磁盘上有瓶颈，则可以将硬盘换为SSD（固态硬盘）。
7.2 服务器参数方面
描述：
从各个业务场景测试来看，服务器方面并没有太大的问题，但是通过页面组件细分图、页面下载时间细分图、第一次缓冲时间细分图以及已下载组件大小图得出需要对StyleSheet.css和categoryId=BIRDS进行优化，同时提升缓存的效率。
解决方案：
1）修改注册表，调整MemoryCacheSize的大小，适当增加。注册表位置在：
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Paramete。(IIS通过高速缓存句柄、目录列表以及其他常用数据的值来提高系统的性能。这个参数指明了分配给高速缓存的内存大小。如果该值为0，就意味着“不进行任何高速缓存”。在这种情况下，系统的性能可能会降低。如果服务器网络通信繁忙，并且有足够的内存空间，则可以考虑增大该值。必须注意的是，修改注册表后，需要重新启动才能使新值生效。)
2）启用HTTP压缩，压缩应用程序文件和静态文件。Gzip是比较常见的一种HTTP压缩算法。这样能减少数据量的传输，从而提高客户端浏览器的访问速度。当然，同时也会增加服务器的一点负担。
7.3 IIS方面
描述：
从各个业务场景测试来看，IIS服务器表现良好，也没有太多的压力。可能这时候大部分人都会忽略从而不会对IIS进行分析。但是，在查看IIS参数时，还是发现了一些问题，并给出了这些问题的解决方案。
解决方案：
1）在IIS中修改内存回收的参数，建议最大使用内存设为1000M，时间段最好设置为半夜。
2）禁止多余的Web服务扩展，建议关闭“所有未知CGI扩展”和“所有未知ISAPI扩展”。在IIS管理控制器中，选中“Web服务扩展”，然后在右侧选择相应的“所有未知CGI扩展”和“所有未知ISAPI扩展”，分别单击“禁用”按钮即可。
3）删除不必要的IIS扩展名映射，例如shtml、shtm等。在IIS管理控制器中，选中站点并单击右键选择“属性”，在弹出的“属性”对话框中选择“主目录”选项卡，然后单击“配置”，在弹出的“应用程序配置”对话框中进行删除即可。
4）关闭访问记录的设置。选中站点，单击右键，选择“属性”，在弹出的“属性”对话框中取消勾选“启用日志记录”即可。
5）如果遇到促销日访问量比较大的时候，建议开启“带宽限制”和“网站连接”，避免服务器死机。

7.4 网络方面
描述：
从各个业务场景测试来看，网络性能良好，不过偶尔也会出现堵塞。
解决方案：
因为网络因素是不可控的，所以为了避免网络造成的影响，可以考虑对前端进行优化，如减少请求、压缩JS和CSS等；同时对后端的计算进行优化，以减少不必要的动态计算，如一些Session计算。
7.5 程序代码方面
描述：
在测试期间，通过随机的访问系统，发现某些元素并没有很好地缓存，在并发比较大的情况下会增加服务器的额外负担和网络传输量。另外，在LoadRunner中也出现了找不到关联值的提示，可能是处理延迟导致。
解决方案：
1）对类似categoryId这样的参数适当增大OutputCache页面缓存的时间，建议调整为100000。
2）重新评估是否需要对VIEWSTATE、EVENTARGUMENT等这样的参数，每次都重新做动态的计算。如果不是，完全可以关闭，这样能有效减少数据计算。
7.6 架构部署方面
描述：
因为资金、资源有限，系统的架构部署并不是最合理的，不过目前可以承受日常的访问，性能也可以达到预期。但考虑到未来流量的增加以及促销活动的推广等，还是建议对架构部署方面做一定的投入，不然当出现性能问题时，损失的不仅仅是金钱，还有公司和产品的口碑。
解决方案：
1）做RAID。RAID（独立冗余磁盘阵列）的原理是利用数组方式来做磁盘组，配合数据分散排列的设计，提升数据的安全性。磁盘阵列是由很多价格较便宜的磁盘组合成一个容量巨大的磁盘组，在提高硬盘容量的同时，还能够提高硬盘的速度，使数据更加安全，更加易于磁盘的管理。
2）做集群与负载均衡。
3）应用服务器与数据库服务器进行分离。
4）提前考虑分库分表策略。