VOC客户之声工作台压测过程及unix系统查看cpu命令

• 准备数据的时候，当专家组中有1000个用户时，发布任务书非常的慢
• 需要模拟多人同时提交任务书，所以用loadrunner压1224个用户（带压测标识的）到系统中，然后放到压测专家组里面，新建2个任务书（带压测标识的 ）时，选择有1224个人的压测专家组，压1224个用户同时提交2个发布的任务书即可
• 提交任务书时并未使用到usercode，所以无需初始化usercode和password，应该是自带了usercode
• 压人员绑定专家组时，出现了loadrunner不报错，事务数能正常增加，cpu没有任何压力，但是就是无法绑定任何人员
• • 重新研究了：loadrunner多用户并发操作解读的帖子，发现是参数化设置有问题，不能用Unique + Once（用这个的话，如果使用10个vusers，就只会生成10条记录），需要用Unique + Each iteration
• 录制提交任务书脚本时，重要感知的题目答案是通过js拼接之后用参数questionsContent传到后台去的，但现在录制下来的内容不知道有什么问题，导致回放脚本时，任务书可以正常提交，但是重要感知的题目答案却为空
• • 分析原因：
  • • 找开发从本地打日志，将压测任务书的questionsContent提供一份，直接copy到脚本里面，试试看行不行
    • 开发说不知道怎么打印日志，自己尝试百度用url解码将questionsContent解码成json
    • url解码之后，重要感知的题目答案仍然为空，找开发在本地打断点，用开发本地的代码来看传过去的json格式是否有误
    • 最后发现answerid也需要参数化，并不是每个任务书的answerid是一致的，而是根据人员来的，每个人每个任务书的answerid是不同的。并且loadrunner录制的json格式无需解码，可以直接使用
    • 在数据库根据feedbackId查找answerid，发现为空，开发协助查看代码，发现answerid是在打开任务书的时候由后台生成的随机码，在loadrunner里面研究打开任务书的方法，发现answerid无法由loadrunner参数化
  • 解决办法：录制2个脚本，一个脚本用来打开任务书，生成answerid；在数据库里面查询生成的answerid参数化另外一个脚本，用来打开任务书提交任务书
• 压测打开任务书之后，数据库查询answerid，发现同一个feedbackId会对应多个answerid
• • 分析原因：一个任务书里面有几道题目，打开任务书之后，同一个feedbackId就会生成几个answerid
  • 解决办法：压测使用的任务书，只采编一道题目，就可以保证参数化的answerid跟feedbackId是一对一的关系
• 我的任务书，提交任务书需要参数化的参数： feedbackId、assignmentId、answerid
• • 第一个脚本用来打开任务书，生成answerid，需要参数化的参数：feedbackId、assignmentId
  • • 查找所有的feedbackId
    • 查找未打开过的feedbackId（未生成过answerid，因为会压测好几轮打开任务书，所以每轮压之前要重新查询未打开过的feedbackId）
  • 第二个脚本用来打开任务书提交任务书，需要参数化的参数：feedbackId、assignmentId、answerid（没有提交过答案，因为会压好几轮提交任务书，所以每轮压之前要重新查询未提交过答案的任务书 ）
  • feedbackId参数化设置为：Unique + Each iteration + Continue with last value（检查一下对应的select column是否正确）
  • assignmentId参数化设置为：Same line as sheetId（记得检查一下对应的select column是否正确）
  • answerid参数化设置为：Same line as sheetId（记得检查一下对应的select column是否正确）

VMSTAT（压测实际使用时，可以每五秒查看一次，用命令“vmstat 5”，关注：free（空闲的物理内存），id（空闲的cpu））

参考：http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html

free   空闲的物理内存的大小。

id  空闲 CPU时间，一般来说，id + us + sy = 100，一般认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。