网络并发测试工具(socket并发测试工具)

我们常常使用apache下的并发测试工具ab进行动态或静态页面URL的并发测试，以此作为服务器性能、配置以及系统架构是否合乎要求的一个衡量标准。 但是有一个问题，就是ab的表现并不稳定，在不同的机器上用ab对同一个服务器上的URL资源做测试常常出现截然不同的数据。就算在同一台机器上用ab做 测试，测试10组数据，也会有几组的数据存在较大的差异，以下是我曾做过的几组试验，先介绍下试验步骤及环境。 1、首先准备一台机器作为web服务器，硬件配置为硬件配置为Intel(R) Celeron(R) CPU G530 @ 2.40GHz 32位 内存4G 双核，系统版本CentOS release 5.5，web服务器版本Apache/2.2.14。2、web服务器采用apache，采用worker模式，具体配置为：默认开启5个进程，每个进程下2个线程，最大开75个线程（此参数关系到实际系统开启的进程数，如果开启进程设置过多，以最大线程数为准），最大连接数为500。3、apache以调用php模块的方式执行php脚本（非fast-cgi模式）。4、首先在两台不同的机器上对此服务器用ab进行压测，将两台不同的机器编号为A与B，A为一台笔记本，性能较差，2G内存，且上面运行了一些程序占用 了一定比率的CPU及内存。B为一台台式机，硬件配置为CPU Intel G530 2.4GHz 内存 4GB，下面是测试数据：A50个并发，执行50次页面（每个连接执行一次页面，页面为phpinfo页面）平均执行时间在17~18秒 简直不能忍B50个并发，执行50次页面平均执行时间在0.2秒左右 毫无压力（3次平均）100个并发，执行100次页面平均执行时间在0.4秒左右 （3次平均）200个并发，执行200次页面平均执行时间在0.8秒左右（3次平均）用A机器进行的测试结果，并发量连50都达不到，但用B机器测试WEB服务器可以胜任200个并发处理。为什么会出现如此截然不同的数据差别，还是要从原理上来分析。ab是客户端模拟多线程来通过socket对服务器发起TCP请求，并等待服务器处理执行页面输出页面结果并返回到客户端以此来计算页面的执行时间等相 关数据。那么客户端CPU处理多线程的能力，测试时客户机的CPU状态、内存状态都会对测试结果造成影响，如果客户机同时处理这么多请求的能力很弱，那么 需要很长时间才能将请求发送到服务器，服务器处理完后也需要很长时间对返回数据做处理，这样就达不到测试服务器性能的要求了。因为时间都被客户机耗去了。 所以我们在测试的时候首先要选择好测试机，尽量选择性能较好的机器测试。因为得出的结论是天差地别的。5、接下来我们单独用B机器进行测试，进行高强度的测试，连续测试20组数据，以200个并发、执行200次页面为测试条件，测试页面还是phpinfo页面，以下是测试数据：每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843每秒请求数：237 每个请求执行时间：843测试结果非常稳定，没有大差异的结果。那么用300个并发、执行300次页面为测试条件结果会是怎样呢，以下是测试数据：每秒请求数：79 每个请求执行时间：3765每秒请求数：80 每个请求执行时间：3718每秒请求数：81 每个请求执行时间：3671每秒请求数：80 每个请求执行时间：3750每秒请求数：79 每个请求执行时间：3796每秒请求数：81每个请求执行时间：3687每秒请求数：79 每个请求执行时间：3765每秒请求数：82 每个请求执行时间：3656每秒请求数： 81 每个请求执行时间：3703每秒请求数： 82 每个请求执行时间：3640在高并发下的执行结果也比较稳定。6、接下来我们在web服务器上进行测试，看测试结果是怎样的，测试10组数据 以200个并发、执行200次页面为测试条件，测试页面为phpinfo页面，以下是测试数据：每秒请求数：1716 每个请求执行时间：116每秒请求数：1764 每个请求执行时间：113每秒请求数：1706 每个请求执行时间：117每秒请求数：1643 每个请求执行时间：114每秒请求数：1767 每个请求执行时间：113每秒请求数：1732 每个请求执行时间：115每秒请求数：727 每个请求执行时间：274每秒请求数：249 每个请求执行时间：801每秒请求数：1728 每个请求执行时间：115每秒请求数：113每个请求执行时间： 1765以上结果，比在B机器上表现的更好，但存在几个不稳定的数据。分析一下，一方面是网络传输速度的原因导致（本机上网络传输速度更快，所以成绩较好）。另一 方面是由于ab本身在执行的时候消耗的cpu的性能，但这个我的观点是影响可以忽略不计。还有一方面导致数据不稳定的因素可能是由于TCP连接在上一次测 试时为完全释放导致的原因。 综上所述，对于测试web服务器的性能，我们最好可以找一台独立的、性能较好的、并且上面没有运行很多应用程序的机器进行测试，这样的结果会更接近生产环 境的实际结果。实际的php页面执行复杂度可能是phpinfo的好几倍，所以在选定测试页面时，可以预先做一些复杂度更高的php页面进行测试，这样测 试的准确度会更高。
打开Apache服务器的安装路径，在bin目录中有一个ab.exe的可执行程序，就是我们要介绍的压力测试工具。 在Windows系统的命令行下，进入ab.exe程序所在目录，执行ab.exe程序。注意直接双击无法正确运行。

LoadRunner，是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。扩展资料：定位性能LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，可以观察到应用系统的运行性能。这些性能监测器为实时显示交易性能数据（如响应时间）和其它系统组件包括application server,web server，网路设备和数据库等的实时性能。这样，就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。利用LoadRunner的ContentCheck TM ，可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助从终端用户角度观察程序性能状况。参考资料来源：百度百科-LoadRunner
做性能测试用的。测试软件的性能、压力、负载情况、服务器的响应时间，吞吐量、监控服务器、数据库的性能指标。等等。总之很强大。
loadRuner 是一款性能测试的自动化测试工具，很强大。可以对软件进行性能测试：压力测试，负载测试，并发测试，可靠性测试等等，可以测试出很多与指标：response time ,user , hit ,resource 等等 体现性能
用于对BS和CS架构的软件，进行压力测试，通过压力测试观察软件的服务器的运行情况，通过对服务器硬件等资源的数据监控，可以看出软件的最大用户数和硬件资源最大的承载点~
性能测试

Apache服务器自带了ab压力测试工具，可以用来测试网站性能，使用简单方便。 工具/原料Apache方法/步骤打开Apache服务器的安装路径，在bin目录中有一个ab.exe的可执行程序，就是我们要介绍的压力测试工具。在Windows系统的命令行下，进入ab.exe程序所在目录，执行ab.exe程序。注意直接双击无法正确运行。执行ab命令成功后，可以看到如图提示。该帮助很清楚详细的介绍了ab的用法以及各个参数的含义。ab 的用法是：ab [options] [http://]hostname[:port]/path例如：ab -n 5000 -c 200http://localhost/index.php上例表示总共访问http://localhost/index.php这个脚本5000次，200并发同时执行。ab常用参数的介绍：-n ：总共的请求执行数，缺省是1；-c： 并发数，缺省是1；-t：测试所进行的总时间，秒为单位，缺省50000s-p：post时的数据文件-w: 以html表的格式输出结果执行测试用例：ab -n 1000 -c 100 -whttp://localhost/index.php>>c:1.html上面的测试用例表示100并发的情况下，共测试访问index.php脚本1000次，并将测试结果保存到c:1.html文件中。测试报告如图，可知在该100并发访问的情况下，共测试访问1000次，失败了852次。可知该脚本在此环境无法满足100并发访问的要求。修改参数继续测试。测试并发50和30两种情况，由测试报告得知，在并发访问降到30时，错误的访问数降为39。 步骤阅读

这属于性能测试的范畴了 主要用的工具就是WinRunner和LoadRunner中文的还不太好找 现在的测试工具比较少，而且基本上都是英文的

主流移动端性能测试工具简述 4.1.Xcode-Instrument　　Instrument是Apple官方提供的一个强大的内置在xcode中的性能调试工具集。其中，Activity Monitor（活动监视器）：监控进程级别的CPU,内存,磁盘，网络使用情况，可以得到应用程序在手机运行时总占用的内存大小；Core Animation（图形性能）：这个模块显示程序显卡性能、CPU使用情况以及页面刷新帧率；Network：用链接工具分析程序如何使用TCP/IP和UDP/IP链接；Energy Log：耗电量监控。Instrument主要用于在调试过程中随时发现问题，及时优化，但是这个工具只能供有应用源码的程序员使用，无法测量用户真实使用场景下的性能。4.2.Android monitor　　Android Studio内置了四种性能监测工具Memory Monitor、Network Monitor、CPU Monitor、GPU Monitor，可以使用这些工具监测App的状态。Memory Monitor工具主要是用来监测App的内存分配情况，判断是否存在内存泄漏；Network Monitor是用于显示App网络请求的状态；GPU Monitor工具可以将进行UI渲染工作所花的时间表现出来；CPU Monitor可以对代码中的方法进行检测。4.3.Matrix　　Matrix是一款微信研发并日常使用的应用性能接入框架，支持iOS, macOS和Android。Matrix 通过接入各种性能监控方案，对性能监控项的异常数据进行采集和分析，输出相应的问题分析、定位与优化建议，从而帮助开发者开发出更高质量的应用。数据监测结果存储到后台，没有直观的展示界面。Matrix-iOS/　　macOS主要监控崩溃、卡顿和爆内存。Matrix-android监控范围包括：应用安装包大小，帧率变化，启动耗时，卡顿，慢方法，SQLite 操作优化，文件读写，内存泄漏等。4.4.GT　　GT（随身调）是直接运行在手机上的“集成调测环境”。利用GT，仅凭一部手机，无需连接电脑，即可对App进行快速的性能测试(CPU、内存、流量、电量、帧率/流畅度等)、开发日志的查看、Crash日志查看、网络数据包的抓取、App内部参数的调试、真机代码耗时统计等。GT支持iOS和Android两个手机平台，其中：　　iOS版是一个Framework包，必须嵌入App工程，编译出带GT的App才能使用；iPhone和iPad应用都能支持。　　Android版由一个可直接安装的GT控制台App和GT SDK组成。GT控制台可以独立安装使用；SDK需嵌入被调测的应用、并利用GT控制台进行信息展示和参数修改。4.5.Emmagee　　Emmagee是一款实用、方便的性能测试工具，适用于指定的Android App，它可以监控CPU、内存、网络流量、电池电流和状态（某些设备不受支持）。此外，它还支持自定义收集数据的时间间隔，在浮动窗口中呈现实时进程状态等。安装之后，打开Emmagee会显示出目前系统已经安装的应用（可在设置中配置间隔）。选择一个应用之后，点击“开始测试”按钮，Emmagee会自动启动被测应用，并在最上方显示流量、CPU、内存等数据，在该状态下可任意使用被测应用，Emmagee会自动进行相关数据的记录，终止测试之后会生成相应的报告，并保存在Android目录中。4.6.Soloπ　　Soloπ是支付宝在移动端上实现的一套无线化、非侵入、免Root的 Android 专项测试方案。直接操控手机，即可实现自动化的功能、性能、兼容性、以及稳定性测试等工作。支持 CPU、内存、FPS、流量等常规指标的实时获取，同时支持将性能数据记录下来，存储到本地并通过报表形式展示，支持性能加压。4.7.Testin　　Testin性能测试，通过自动化的测试工具，在上线前模拟正常、峰值以及异常等多种场景，从而对App的各项性能指标进行测试。包括：负载测试、压力测试、配置测试、并发测试、容量测试、可靠性测试。负载测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量。　　压力测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能够提供的最大服务级别。配置测试：通过测试被测试软件的软硬件配置，获得不同配置的性能指标，用于选择最佳的设备及参数配置。并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 容量测试：在确定的软、硬件条件下，构造一定数量的虚拟用户访问，从而获取不同数量级别的服务器性能指标，以确定数据库能够处理的最大会话能力、最大容量等。