看你在4楼的图就已经可以确定是网络或配置问题了，代码方面的优化可以先不提。
看weblogic线程队列最大值给的多少，队列长度多少，数据库连接池配的多少，是否局域网内测试，客户端到weblogic ping值多少，weblogic ping数据库又是多少，有没有防火墙控制。 原帖由 tttrrryyy 于 2010-7-20 15:56 发表 http://bbs.51testing.com/images/common/back.gif
降低并发数，从1加到10，看什么时候出现瓶颈，也就是吞吐率不再上升。
看你在4楼的图就已经可以确定是网络或配置问题了，代码方面的优化可以先不提。
看weblogic线程队列最大值给的多少，队列长度多少，数据库连接 ...
参数方面其实已经有多个Orcale那边的专家来调过，国内的有，新加坡的也有，能调的其实都已经调了，还请了个法国人用代码写了缓存的程序，效果从很烂变为了烂，其实产品本身就有问题，现在想把除产品以外所有因素调到最优，并要拿出证据跟客户解释已经调无可调，让他们接受事实，本身他们选择的产品就这样，不是我们的关系。。。 我觉得首先要确定的问题是
最开始只加载50用户
为什么50用户的点击率和吞吐量就会那么高
建议你用50用户多跑一会
拿出稳定的数据分析一下
还有个建议
从10用户开始增加
间隔稍微长一些(保证数据是有效的)
比如每20分钟增加10用户
看看点击率和吞吐量的拐点到底在哪 来学习 很明显的网络瓶颈啊。。。
你的throughput都超过不了12M，属于百兆范围的。。我以前做的时候，也遇到这情况的，门户网站，图片，js，css太多了，很占带宽的
建议你，不要去从负载做压力测试了，找2台机器，直接压你们的应用服务器就可以了。效果会有质的飞跃。你的压力发生器要和你们的应用服务器在同一网段哦~~ 原帖由 zl861216 于 2010-7-21 17:12 发表 http://bbs.51testing.com/images/common/back.gif
很明显的网络瓶颈啊。。。
你的throughput都超过不了12M，属于百兆范围的。。我以前做的时候，也遇到这情况的，门户网站，图片，js，css太多了，很占带宽的
建议你，不要去从负载做压力测试了，找2台机器，直接压你 ...
是指类似直接去机房压？
回复 26# 的帖子
直接压你的APP应用服务器比如说，修改脚本中url的地址就可以了
比如你现在的地址为www.123456.com，需要修改为你们的服务器地址，比如说10.192.22.234,当然需要开发和运维那边来支持你的，也就是说，输入10.192.22.234要能访问到你们的应用，不知道我这样说，你能不能理解。
回复 27# 的帖子
我现在是用IP直接压的，没有用域名 原帖由 zl861216 于 2010-7-21 17:12 发表 http://bbs.51testing.com/images/common/back.gif很明显的网络瓶颈啊。。。
你的throughput都超过不了12M，属于百兆范围的。。我以前做的时候，也遇到这情况的，门户网站，图片，js，css太多了，很占带宽的
建议你，不要去从负载做压力测试了，找2台机器，直接压你 ...
如果是这种情况的话，可以只压接口服务，这样就可以排斥是不是门户图片、js的影响了。 建议楼主还是一步一步的排查
判断时不时网络瓶颈的手段很多
发现这里有的人很不低调
好像什么问题都一眼就看的很明白
论坛里很多高手都会先提出一些疑点
然后才慢慢判断的
性能问题定位是一个逐渐深入的过程
不要搞得好像明显高出别人似的 别人的问题到你那一眼就有结果了？
建议楼主还是慢慢来吧
23楼我提供的方法可以试用一下
回复 28# 的帖子
你要去运维相关人员那去确认一下的，看看你的压力发生器和你的app服务器之间的带宽多大。。门户网站我做的多了，信不信由你~！
回复 30# 的帖子
很明显的问题，就不需要复杂化~~~既然有过经验，就要拿出来分享~~~
你没遇到过类似的情况，就不要瞎出主意
产品快上线了，时间有多紧，你又不是不知道~~！！ 原帖由 zl861216 于 2010-7-22 11:16 发表 http://bbs.51testing.com/images/common/back.gif
很明显的问题，就不需要复杂化~~~
既然有过经验，就要拿出来分享~~~
你没遇到过类似的情况，就不要瞎出主意
产品快上线了，时间有多紧，你又不是不知道~~！！
看来在你眼里什么问题都很简单了
你怎么知道我没遇到过类似的问题
性能测试需要从很多方面去定位问题
怎么在你这看两个图就能定位了
回复 9# 的帖子
我觉得您的最后那两幅图能说明您所测的web网站的性能测试存在问题，或者存在网络延时等情况。因为当用户数达到稳定状态时，TPS和平均响应时间波动实在是太大了，您觉得呢？ 原帖由 zl861216 于 2010-7-22 11:16 发表 http://bbs.51testing.com/images/common/back.gif
很明显的问题，就不需要复杂化~~~
既然有过经验，就要拿出来分享~~~
你没遇到过类似的情况，就不要瞎出主意
产品快上线了，时间有多紧，你又不是不知道~~！！
典型的半瓶子咣当型选手
就你一个人懂性能测试被
估计也就是在个小公司做测试的
你要真是在百度搜狐淘宝的也行 算你牛逼
要不就别装大了 原帖由 shigui3615 于 2010-7-22 19:43 发表 http://bbs.51testing.com/images/common/back.gif
我觉得您的最后那两幅图能说明您所测的web网站的性能测试存在问题，或者存在网络延时等情况。
因为当用户数达到稳定状态时，TPS和平均响应时间波动实在是太大了，您觉得呢？
请详解，你的意思是应该平稳在高位，不应该出现向下的波动？？？ 原帖由 z3z3z3z3 于 2010-7-20 15:37 发表 http://bbs.51testing.com/images/common/back.gif
我怎么看服务器端的带宽？
按照公式：1.5M*8*400/5=960M/s，服务器千兆带宽应该够吧
诶呦呦，960M/S厉害哦~:L
百兆的路由哦，理论速度是12.5MB/S吧不信你可以用飞鸽传文件算算 超过这个是不可能滴
千兆带宽哦，理论熟读是125MB/S 不信...
较好的服务器硬盘算你6Gb/S，理论速度是800MB/S
换千兆的路由没的效果，说明服务器网卡是百兆滴~
外话：人数增加，吞吐量不变，那是不可能滴
不变的可能是速率，总量是绝对要上去滴，响应时间是绝对要慢下来滴，如果是这样网络就是瓶颈滴
当然，万事不靠谱，还得具体问题具体分析滴，各个场景不同也不能一概而论滴
我们平时在算速率时用的是Bit，在标注一个硬件有多快时候也是用Bit
但体现在直观层面上，我们更希望看到的是Byte，就像很多流量小工具一样都用这个，只不过换成KB的给你显示出来，也就有了常有的KB/S之类的
Loadrunner上用的是Byte
还是算清楚来比较好，一差差好多的
大家弄个360流量监控之类的，你看看，在并发要过的时候，你的流量达到多少了？直观明了啊~还每个虚拟用户进程都给你标好哈哈~
别忘了服务器上也搞个
记得关网盾实时保护之类的
[ 本帖最后由 twinsczl 于 2010-7-23 17:13 编辑 ]
回复 37# 的帖子
请教了，1.5M(bytes) * 8 * 400(人) / 5(s)=960M(bits/s) 有问题吗？关于带宽，客户明确说明了服务器端是千兆的 原帖由 cen0225 于 2010-7-23 10:12 发表 http://bbs.51testing.com/images/common/back.gif
请详解，你的意思是应该平稳在高位，不应该出现向下的波动？？？
网上看到的观点：
事务通过数的意思是每个特定时间间隔内通过的事务数，如果随着场景执行时间的推延，通
过事务数曲线应该是平缓的，如果突然上升，则可能是服务不稳定，或者网络因素导致的，
如果持续下降，则表示服务的处理能力在下降，此时可以查看服务器段是否有进程堵塞，或
者服务器的连接数不够，也可能是网络带宽不够.
平均事务响应时间在整个测试过程中是一个很重要的参考指标，他能清晰的反映出场景
执行过程中，每个事务的执行时长，整个业务中哪个操作最耗时等等。场景执行结束后，可
以根据这个图表分析出在一定响应时间要求下，系统可支持的并发数，假如我们要求在查询
的时候要求这个返回结果的时候不超过5 秒，那么可以在场景中找到对应的SubQue 事务在
处理时间为5 秒左右的时间点，再从Running Vuser 图中找到对应的时间点，查看对应的并
发用户数。同样，在整个执行过程中，当并发数达到一定数值后，平均事务响应时间曲线应
该是平缓的，如果出现突然升高或者降低的情况，则表示系统存在异常，这样我们可以找到
这个时间点去查看服务器端的运行日志，查找原因.
回复 38# 的帖子
找个和生产环境同一个网段的负载机，压一下，就知道了嘛~！！如果不出意外的话，你们的网络流量会飙升上去，你的hits per second会高达3000以上的，这时，有可能会出现LoadRunner自生的链接与释放问题，去网上搜一下，去注册表里改个参数就可以了，当然，如何没有出现问题，就更好了~~~~~
同时你的throughput也会飙升上去的，你的服务器CPU利用率也会上去的。
