性能测试步骤.docVIP

性能测试步骤 性能测试步骤.txt永远像孩子一样好奇，像年轻人一样改变，像中年人一样耐心，像老年人一样睿智。我的腰闪了，惹祸的不是青春，而是压力。。。。。。当女人不再痴缠，不再耍赖，不再喜怒无常，也就不再爱了。性能测试步骤（一）——熟悉应用 由安博测试空间技术中心/提供 这是整个性能过程最关键的步骤之一，毋庸质疑。 我们必须了解：应用的架构 以我熟悉的应用类型为例。了解了应用架构，我们才能知道，我们需要模拟的是：一般的html静态文件请求、一般的servlet和jsp请求、AJAX请求、还是远程调用请求等。 我们必须了解：应用的功能逻辑 性能测试步骤（二）——测试需求 我们得到的测试需求往往是这么描述的：这个系统能否支撑100万的uv（每天登录系统的人次）。 言下之意是：按照目前的硬件性能和数量，系统能否支撑100万的uv。 然而，我们了解的是吞吐量、响应时间等指标 吞吐量：系统每秒能处理的请求数，这个指标从服务器的视角，表征系统容量 响应时间：从请求发出到第一个字节返回所需要的时间，这个指标从用户的视角，表征系统响应速度。 那么，请问开发同事：能把测试需求转化成我们熟悉的吞吐量和响应时间吗？ ...... 答案常常是否定的 怎么办：只能由我们根据经验，把100万uv转化成一系列的指标。 响应时间：根据国外的一些资料，一般操作的响应时间不能高于3~5秒；重要操作，如结账操作的响应时间不能高于15秒。 吞吐量：可以根据已经上线的类似产品进行估计。或者，采用80/20原则进行估计。我们经常使用的是80/20原则。 虽然已经有了响应时间和吞吐量指标，但是测试需求还是不明确的。 我们的测试目的是什么？ 是验证当前硬件和软件配置能否支撑100万uv？是测试当前的硬件和软件配置最多能支撑多少uv?是帮助开发寻找性能瓶颈？ 答案往往是：都要！ 根据我们的经验，开发的需求往往是这样的（当然开发一般不会说得那么详细，^_^）： 首先，请你们验证能否支撑100万uv。如果不能支撑，请找一下性能瓶颈。主要性能瓶颈解决后，请估计能支撑多少uv，如果不到100w，请估计要加多少机器。如果能支撑100万，请再加压，看看达到300万uv的时候，系统的性能。这么一细化，需求基本明确了。 性能测试步骤（三）——测试准备 测试准备包括测试客户端机器准备、测试数据准备、测试脚本准备。 客户端机器：要足够，否则，如果瓶颈在客户端，就无法评估服务端。要和服务器保持网络通畅，否则，如果瓶颈在网络，也无法评估服务端。包括：网络带宽要高于服务器吞吐量、网络带宽要稳定。 测试数据 如果被测功能涉及数据库和高速缓存，通常需要预设很大的数据量才能凸显性能瓶颈，这通常是挺困难的一个环节。 如果是已经上线的应用，数据可以从线上拷贝得到；如果还没有上线，那需要构造类似于线上的数据量。 比如，要测试群聊性能，我们首先需要注册大量用户；然后把测试用户都加入到聊天群中。 测试数据准备的脚本，有时候比测试脚本本身还要多。 对于实在没有办法构造大数据量的情况，如果要测试高速缓存，我们有时候会按数据量的比例减少高速缓存，以使测试结果尽量准确。 测试脚本 Grinder脚本用jython实现 测试脚本的实现往往会花费比较长的时间 因为涉及到应用实现的细节，需要和开发不断交流才能完成。这也是需要了解应用架构的原因之一。 关于sleep time 基于真实模拟的考虑，sleep time还是尽量按照真实时间，并给一定的偏差。 不过对于测试客户端来说，sleep time往往会引起很多客户端测试线程的调度，浪费客户端系统资源。 Sleep time越小，客户端能模拟的吞吐量就越大，所以，实际测试中，我们往往会把sleep time设置为0 。 性能测试步骤（四）——测试执行 测试的执行中，需要监控测试客户端和服务器性能，监控服务器端应用情况： 客户端的系统资源（cpu、io、memory）情况 服务端的系统资源（cpu、io、memory）情况 服务器的jvm运行情况 服务端的应用情况，看是否有异常 响应时间、吞吐量等指标 系统资源监控，linux下可以采用的工具有：vmstat、top、meminfo等。 JVM的监控，可以用jprofiler工具，linux下面的jmap、jhat等。 响应时间、吞吐量等，由grinder提供。 上述这些信息，一般在测试结束后，均需要归档整理，已备后续详细分析 我们自己开发一套脚本，用于以固定的频率获取测试客户端和服务器的vmstat和top输出、grinder的log，并从中截取有用信息保存，用于事后分析。 每次测试运行完以后，肯定会增加很多数据，需要考虑本次执行对数据量的影响，如果数据量的变化对后续测试会有影响，则需要清理数据。 性能测试步骤（五）——测试分析