参数设置
楼主，感谢你共享文章。在你的文章中多次提到的“参数配置”，对性能有很大也很重要的关系；请问你针对
服务器操作系统、中间件瓶颈等如何进行参数配置？ 好文不能不顶 1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
——还要考虑页面错误的情况；
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
——能否具体说说为什么这种情况说明存在处理器阻塞？
——在Unix/linux 操作系统，当CPU利用率低，但是事务响应时间仍然较长时，还需要观察 I/O Wait 的变化，以鉴别是否因为 I/O 导致 CPU 利用率低；
非常感谢楼主总结自己的经验来与大家分享 ^_^ 相当不错 不错 受益匪浅啊，谢谢楼主！ 非常感谢楼主啊，正在找这方面的东西，楼主就发上来了，真是雪中送炭啊！
再请问一下楼主，UNIX资源监控中指标内存页交换速率（Paging rate），这个值一般为多少认为正常呢？？？
超过什么范围认为高呢？？？ great 谢谢楼主！ just so so 拷下来了，谢谢了先 非常感谢！ 谢谢楼主了！！！希望以后能分享更多宝贵经验。。。。。。 正在学习性能分析阶段！感谢！ 多谢搂住！ 。。。。。。真的是这样么?!!!怀疑ing.^_^
我一直以来从事压力测试想法都和你写的一样,但是最近好像感觉似乎这样测试是不正确的.
我把我的想法写一下大家看看是不是有什么地方不对。；P
测试目的:
我们做的是软件测试,测试的对象应该是软件.但是现在这种测试方法却把硬件资源也加入到软件测试之中了.并且以硬件资源的占用来衡量软件性能.似乎是走到了一个误区.后面我会举异步处理的例子。
测试方法:
分段排除法我认为可以理解。但是服务器硬件瓶颈是在第一轮就已排除了，怎么可以用到后面对软件性能的评估当中？也就是说一楼帖子中的“分析信息来源”中的服务器cpu men io 等资源占用情况的数据分析是否还属于软件性能测试的有效数据依据。
当并发数的测试遇到异步处理：
并发概念在遇到异步处理机制时似乎被完全颠覆了，异步处理机制的目的本身就是为了优化大并发量时server的处理性能。因此在给异步处理机制的系统做压力的时候系统资源占用数据变化极小，并且在高并发数压力下同样能处理正常而不占用大量资源。此时对server资源的监控已经基本失去意义。而且与此同时并发数也失去实际意义--压20和压2w对server来说无明显变化,如何判断支持最大并发数是多少呢?
工具真的能压出软件的真实性能么?
引用牛人的一句话:性能瓶颈不是靠工具测试出来的,而是开发和测试人员一起分析出来的.
吃饭先了 呵呵
[ 本帖最后由 小灰尘 于 2006-3-28 15:58 编辑 ] 我是ash 呵呵
[ 本帖最后由 小灰尘 于 2006-3-28 15:58 编辑 ]
to PCL(pcl = ash ?)
老兄的想法和认识都很好。但对你想法，我谈谈自己的看法：
我们是作软件测试，但软件是运行在硬件上的一种载体，如果剥离硬件、网络，单谈软件的性能，有点虚。所以我个人认为，性能测试（并发负载压力）的对象不仅仅只是软件，应该是整个系统，包括软件、硬件和网络。
由于我们无法知道软件的性能如何，所以我们只能依靠硬件、网络的一些计数器和响应时间来体现，通过这些计数器来进一步分析问题所在。站在测试人员的本质工作的角度上讲，我也认为我们作性能测试应该尽量去发现软件中的问题，对软件进行调优。但调优的工作难度、工作量都很大，我们不可能一遍遍的去作，所以只能以制定的性能指标为衡量需不需要调优的标准。
对异步处理机制的系统，由于其处理方式已不同，所以当然不能用客户端的并发用户数来衡量其性能，其性能指标我认为应该按照吞吐量（每秒的处理事务数）来衡量。
“性能瓶颈不是靠工具测试出来的,而是开发和测试人员一起分析出来的.” 我非常赞同这句话，但如果没有测试工具执行的测试结果，那我们只能一句句地去分析代码。工具不是万能的，但没有工具也是很难的
