本节书摘来自异步社区《loadrunner 12七天速成宝典》一书中的第2章，第2.6节第二个性能测试案例，作者陈霁，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.6 第二个性能测试案例
云云：烤鱼吃得很爽。
恋恋：就是你非要吃香辣味的，害得我嘴巴都麻了。
云云：香辣味的好吃，就是鲶鱼吃得有点腻，能吃黑鱼就好了。
恋恋：下次多找几个人一起吃饭啊，这下他们生意就更好了。
云云：那么我问你一下点一样的鱼和点不同的鱼有什么区别？
恋恋：嘿，你又要考我啦，其实刚才你还没提问，我脑子里面就在想这个问题了。
云云：哦，美美狗开窍了？
恋恋：不但我是美美狗还是聪聪狗，你那点小花样我早看出来了。
云云：那么你说说，让我欣赏一下你的“光芒”。
恋恋：这个问题按照你的思路，我可以先从我公司门口的食堂说起，一般食堂都有固定的菜色，因为烧同样的东西处理能力强、成本低，而如果为每一个顾客单独炒菜，那么成本就会高很多。
云云：你这个跑题有点远啊！
恋恋：所以作为顾客，我们一般几个人都点相同的菜，这样厨子烧的快，无论从配菜，到烧菜都会并行处理。总的来说就是，如果每个人都要不同的东西，会让一个饭店很忙，处理能力降低，而如果要的东西类似，那么就会极大地提高处理效率，从而增加营业额。
云云：哎哟，貌似靠谱了。
恋恋：作为软件系统来说也是这样，如果每次对服务器发出的请求不同，那么服务器也会为每一个请求单独计算，从而会让服务器很忙，提高效率就是要让客户做的事情尽量相同，然后服务器就可以并行处理了。
云云：嗯，不错，不过有些不太专业。
恋恋：比如a和b做相同的请求，那么对于数据库来说查询的内容都相同，那么就可以只计算一次，然后内容就可以一次发给客户啦，就好像两个人都点宫保鸡丁炒饭一样，一次炒制，两盘出锅。
云云：虽然请求相同，但是可能因为业务不同而导致结果不同啊，比如a是管理员能看所有的记录，而b是普通用户只能看自己的记录！
恋恋：这个……
云云：那你觉得请求应该相同还是不相同呢？
恋恋：我觉得请求应该不同，因为你既然让我把脚本动起来，还给我说怎么做参数变量、处理业务，本质上就是要让每次输入的东西都不一样。
云云：没错，如果每次请求都一样，那么服务器会自动使用cache机制，这也是一个使服务器提高处理能力的策略，当发现请求或者查询内容相同，系统会先从缓存（内存）中查找是否存在匹配的记录，如果有就返回，否则就执行一次，将结果存放入缓存，唯一特例就是所谓的要做及时查询，就是锁概念。
恋恋：嗯，我也听说过什么memcache、pga&sga还有啥jvm内存管理，都是和缓存有关系，锁这个概念我就不太懂了。
云云：锁这个概念怎么说呢，这样吧，你知道12306买火车票难吧。
恋恋：知道啊，不知道谁做那么差个系统，查个火车票都经常刷不出来。
云云：这就叫做外行看热闹，内行看门道。其实做火车订票系统是很难的，因为查票是及时的，要锁定票。
恋恋：go on！
云云：每当一张票被订的时候，所有的查询都要得到全新的少了一张票的情况，所有的订票都要告诉别人这个位置的这个票已经被订了。所以当成千上万的人去买票的时候，一张票被锁定会影响几万个查询，每次查询都不能用cache，否则会得到错误的信息，你明明看到这个票有，但是订的时候却失败。
云云：这里面还有更复杂的业务，比如从上海到北京的高铁，如果我订了一张从南京到天津的票，就意味着会多一张上海到南京的票，还有一张从天津到北京的票！
恋恋：那么怎么优化呢？
云云：很简单，首先不要做及时查询，例如不要直接给每个客户看有多少张剩票，其次当一张票订了后，不要立即计算出可能导致生成的部分路程的票，最后将坐全程的票和坐半程的票位置分开做表分离，这样就算买了半程票影响的记录会比较少，处理起来相对简单，让专门的服务器去处理多程票！
恋恋：来吃个梨，你看又进入状态了吧，后面一个人就亢奋的说啊说啊，完全不管别人懂不懂。
云云：真是好心没有好报，看在你给我削梨的举动上就原谅你了。睡觉前是不是可以做第二个性能测试案例了啊。
恋恋：今天晚上要做啥啊？
云云：做一个脚本比较一下点击相同的帖子和点击不同的帖子的性能有何区别！
恋恋：好，开工。
**小结
理解动态访问会带来的负载点及系统处理业务的逻辑概念。
录制脚本运行
**
恋恋：打开lr启动vugen录制一个脚本。
云云：别忘了你首先要有那么多帖子，否则你查询不到。
恋恋：对，那么先录一个生成帖子的脚本吧。
（几分钟过去后）
恋恋：脚本生成。
恋恋：这里我用了一个循环，做了1000次。
云云：那么你发帖的那个参数是？
恋恋：{topic}啊，这是我定义的一个时间参数，这样每次帖子都不一样，如图2-23所示。
云云：哎哟，不错哦。
恋恋：好了，单击运行，我去给你削个梨。
云云：好！不过，如果你用场景，运行会快一些。
恋恋：好啊，你自己削梨去，eq真低。
云云：我错了，还是你帮我削吧。
（几分钟后，帖子生成）如图2-24所示。
恋恋：接着我要录制一个用户随机访问帖子的脚本和一个用户访问一个固定帖子的脚本。
恋恋：找到看帖请求的那个函数，然后将这个请求内容做一个参数化，参数名称叫作tid，并且设置从1～1000的随机数，如图2-25所示。
恋恋：最后还要在查询前后加个事务，让脚本运行的时候能够统计响应时间，先来试着运行一下。
恋恋：代码运行大功告成！
云云：值得表扬！
（分别运行未参数化和参数化过的脚本）。
恋恋：好像查询条件是随机的会慢一点。
云云：go on。
恋恋：ok，搞定两个脚本，一个是原脚本，查询条件不变的；还有一个是查询条件是随机的内容，接着分别到场景里面去运行一下。
恋恋：场景里面要添加监控内容（windows资源），单击开始运行。