8 个解决方案
#1
上网找点性能测试的报告看看……
#2
报告是看得多了,知道需要监控哪些资源,当发现性能有问题时,不知从哪里来的问题。
#3
建议以“实用主义”来看待性能测试。
性能是否过关,要预先根据用户实际使用场景来设定性能基线,只要软件满足性能基线,也就满足用户的性能需求,没有必要一味的最求高性能,这种属于过度投资,是浪费。
如果对于性能无法满足需求时,针对具体功能项,详细测试各个步骤时间,可能需要给出内部处理流程的详细日志,以便分析性能瓶颈。
性能是否过关,要预先根据用户实际使用场景来设定性能基线,只要软件满足性能基线,也就满足用户的性能需求,没有必要一味的最求高性能,这种属于过度投资,是浪费。
如果对于性能无法满足需求时,针对具体功能项,详细测试各个步骤时间,可能需要给出内部处理流程的详细日志,以便分析性能瓶颈。
#4
其实我做了几次性能测试,从整个测试结果来看,已经满足了用户性能需求,但是偶尔会出现一些意外,比如响应时间突然大挝多,曲线又有中断现象,而且有时CPU、内存利用率达到80%以上的情况。
#5
有拐点就说明有问题~
#6
不同的问题可有不同的测试结果,不能一片而论。
比如说:比如外部条件不变的情况事务响应时间突然波动挺大,测试过程中曲线中断等。。。。
是变大还是变小?变小可能的原因就是加压过程中,测试是否停止。
变大可能的原因就是加压过程中,是否出现网络终端、数据异常等情况。
比如说:比如外部条件不变的情况事务响应时间突然波动挺大,测试过程中曲线中断等。。。。
是变大还是变小?变小可能的原因就是加压过程中,测试是否停止。
变大可能的原因就是加压过程中,是否出现网络终端、数据异常等情况。
#7
呵呵,又见问答题。。。。。
#8
现在系统受影响因素多元化,很多都不能定性来看的。
唯一不变的就是变化。
#1
上网找点性能测试的报告看看……
#2
报告是看得多了,知道需要监控哪些资源,当发现性能有问题时,不知从哪里来的问题。
#3
建议以“实用主义”来看待性能测试。
性能是否过关,要预先根据用户实际使用场景来设定性能基线,只要软件满足性能基线,也就满足用户的性能需求,没有必要一味的最求高性能,这种属于过度投资,是浪费。
如果对于性能无法满足需求时,针对具体功能项,详细测试各个步骤时间,可能需要给出内部处理流程的详细日志,以便分析性能瓶颈。
性能是否过关,要预先根据用户实际使用场景来设定性能基线,只要软件满足性能基线,也就满足用户的性能需求,没有必要一味的最求高性能,这种属于过度投资,是浪费。
如果对于性能无法满足需求时,针对具体功能项,详细测试各个步骤时间,可能需要给出内部处理流程的详细日志,以便分析性能瓶颈。
#4
其实我做了几次性能测试,从整个测试结果来看,已经满足了用户性能需求,但是偶尔会出现一些意外,比如响应时间突然大挝多,曲线又有中断现象,而且有时CPU、内存利用率达到80%以上的情况。
#5
有拐点就说明有问题~
#6
不同的问题可有不同的测试结果,不能一片而论。
比如说:比如外部条件不变的情况事务响应时间突然波动挺大,测试过程中曲线中断等。。。。
是变大还是变小?变小可能的原因就是加压过程中,测试是否停止。
变大可能的原因就是加压过程中,是否出现网络终端、数据异常等情况。
比如说:比如外部条件不变的情况事务响应时间突然波动挺大,测试过程中曲线中断等。。。。
是变大还是变小?变小可能的原因就是加压过程中,测试是否停止。
变大可能的原因就是加压过程中,是否出现网络终端、数据异常等情况。
#7
呵呵,又见问答题。。。。。
#8
现在系统受影响因素多元化,很多都不能定性来看的。
唯一不变的就是变化。