9月1日
机会来了，终于独立实践了性能测试，而且一参与性能测试，调优的进程加快了很多，照目前的进度也许本周就可以完成。倒底是怎么回事呢，下面就来讲一讲。
我来后参与的这个项目离发布的时间越来越近了，这个项目的性能测试的工作一直以来是由小组长进行的，由于该项目是公司内部生产数据的部门使用，该部门目前大概有员工200人左右，故小组长就用了200Vuser来进行压力施加，匹配的服务器是一台8G内存4核CPU的win2003系统。测试结束后，各个业务的性能指标从报告来看都很差，服务器资源几乎耗尽，结论当然也是不通过，需要进行性能调优方面的工作。项目经理和开发拿到相关报告后呢就傻了眼，因为只知道有问题，但不知道问题在那儿，调优根本无从下手，在这种状态下争吵也就发生了。
小组长：“我的思路是用可能的最大压力对服务进行施压，尽快的、一次性都把问题暴露出来。然后你们根据问题进行调优就可以，什么时候OK，什么时候就结束了。我每次发报告让你们进行调优、调优，你们都不进行，老让我重新测试、测试，总怀疑结果，但我每次测试出来的结果又差不多。到现在了还在逃避责任，不思考怎样解决而去怀疑方法的问题”。
项目经理：“我们不是逃避责任，如果真逃避还开这个会干啥。我们是为了找到问题点在那里，消除争议。而且我们一直认为这种测试方法是有问题的，一共数据部才200人，怎么可能同时施加压力嘛，退一万步来说，即使这样你报告只说了这里有问题、那里有问题，到底是那里的问题、能不能具体到方法或者某一个模块，你叫我们怎么调优、从何处下手？”
小组长：“我这样做是为了尽快的暴露问题，在最大压力下所有问题都暴露了，那不是最好的方式么？而且人家的需求就是200用户并发嘛，我这样做是按用户需求文档进行了。致于分析问题的原因那是你们的工作呀，你们都分析不出来，我怎么又能呢？”
项目经理：“你这样说，我们没法做了，调优也是一步一步的，怎么能这样呢？”
小组长：“什么这样、那样，我觉得我的方法没错，你们就是不想调优，在推脱！”
项目经理想说些什么，又觉得无语可说，憋了很久，然后对测试经理说到：“我们也想早点调优完成，尽快交付，现在性能测试和调优都搞了一个月了，也没什么进展，离项目结束也只剩下一个月的时间了，如果继续这样，对大家都是不好的”。
测试经理：“嗯，说得有道理，那你认为目前阶段应该怎么办呢？”
项目经理：“还是得重新测试，测试方法上一下子不要那么大的压力，一步一步的来嘛”。
小组长：“我觉得我没错，前前后后折腾一个月了，我不想再重复劳动了。你们觉得我方法有问题，那你们换人吧”
项目经理：“你怎么这样？”
小组长：“我就这样了”，说完小组长就起身离开了办公室，空气瞬间凝固了。
测试经理：“这样吧，后续的配合工作就交给文字来试一试。她的态度的确不妥，等她冷静一会儿，我再找她沟通、沟通”。
于是这个工作就轮到了我的头上，有种救火队员的感觉。当然当时心理也不是百分百能搞定的，虽然看了不少资料，但一直没有实践过，还是有些担心的。
说干就干，当天我就把一个基础业务的脚本重新生成，并且做好了关联和参数化，也是觉得好奇虽然脚本生成仍然用的是web_custom_request方法走HTTP协议，但整个BODY却是XML，像下面这张图中的样子。
看到soap关键字，隐约记得好像有一个SOAP协议的，便查了一下百度对它的解释：
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<getSupportCity xmlns="http://WebXml.com.cn/">
<byProvinceName>广东</byProvinceName>
</getSupportCity>
</soap:Body>
</soap:Envelope>
其中的<soap:Body>里面的内容就是请求的内容，请求的方法为getSupportCity，该方法有一个名为byProvinceName的参数，参数的值为“广东”这个字符串。再看一下返回的内容。详细见：http://blog.csdn.net/tianlincao/article/details/7654166
就突然明白，原来SOAPAction: "http://WebXml.com.cn/getSupportCity"或者Body字段后面的第一个节点就是程序的方法，那么我只需要将每个请求中的方法名字找出来，然后定义成一个事务，这样岂不是就知道了每个请求的时间，如果谁最慢，那么就调优谁，就解决了问题在哪儿的问题了。
解决了这个问题，然后我也吸取了小组长的教训，确实一来就给200Vuser的压力可能不大合适，按照二八原则，最有可能的应该是20%的用户给予了80%的压力，所以最开始的虚拟用户数可能设置为200*20%=40个可能较合理，即然支持不了这么多，那么我们第一步就应该探索能支持好多并发数嘛。
于是就按照这两个方法，很快的我进行了初步的测试，结果才加载到10个并发用户，查询数据的请求都超过了10秒，而且CPU用了40%左右，问题便很明确了。将问题发给开发，没多久开发便进行了修改，性能也提高了很多。
一天就这样结束了，同时我也明白自己是完全可以承担这份工作任务的。
愿明天会更好！