实时警报通知：微信告警通知的重要性解析
857
2023-02-14
包含java系统性能测试的词条
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈java系统性能测试，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享java系统性能测试的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
高性能、高并发、高可用。
听起来非常高大上，但是性能到底如何呢？又该如何评定呢？
这次我们谈一谈性能测试，看一看到底什么样才叫做高性能。
本文主要从以下几个方面进行讨论。
（1）性能测试是什么？
（2）为什么需要性能测试？
（3）性能测试如何做？
（4）有哪些性能测试的工具
老马曾经说过，你想理解一件事物，首先必须先定义它。
这里直接引用一下百科中的定义：
性能测试的定义也不难理解，往往定义本身阐述了性能测试的作用。
如果你是一名开发、测试，平时接手过不少需求，可能性能测试接触的也不多。
每一个需求，都有对应的功能性需求和肺功能性需求。
功能性需求是产品需求文档中最直接的，需要实现的功能目标。简称，能用就行。
非功能性需求则要宽泛的多，架构设计是否合理？是否便于后期拓展？是否便于监控？代码实现是否优雅？文档注释是否完整？
就像你写了一只鸟，鸟头做螺旋桨非能飞起来，但是在架构设计上可能是不合理的。
飞起来
一个查询功能，用户点击查询，10S 种才返回数据，功能上是满足的，但是性能上是不能接受的。
线上的交易功能平时各方面都很棒，节假日高峰期直接系统就瘫痪了。
那如何避免这些问题出现在生产上呢？
这就需要上线之前，首先做好对应的性能测试，避免再生产上出现问题，带来严重的生产事故。
性能要高，性能要硬，性能测试，又高又硬！
又高又硬
做一件事情之前，我们首先要确定好自己的目标。
性能测试，到底要测试什么？
有些类似于开发过程中的需求分析，常见的测试指标如下。
响应时间是指某个请求或操作从发出到接收到反馈所消耗的时间，包括应用服务器（客户端）处理时间、网络传输时间以及数据库服务器处理时间。
作为用户而言，在页面点击查询，等待了多久才能获取结果，这个就是响应时间。
用户不关心你后端经过了多少个服务，慢就是原罪。
对于微服务系统，链路监控就显得比较重要。可以帮助我们快速定位到底慢在哪里。
TPS（Transaction Per Second）是指单位时间（每秒）系统处理的事务量。
我看网上还有很多类似的概念：点击量/点击率、吞吐量/吞吐率、PV/UV，这里不做赘述。
个人看来本质上 TPS/QPS 就是去压测你应用的极限，当访问量较大的时候，程序能否活下来？
这里主要涉及到两个概念：高性能和高可用。
我们后面会简单讨论下这两点。
明确了测试指标之后，就需要进行测试的准备。
环境准备：比如你想压测数据库，那就需要准备对应配置的数据库资源。
脚本的准备：数据初始化脚本，调用脚本等。
这个可以类比开发过程中的代码开发。
ps: 性能压测一般不是很常用，所以环境准备流程会比较长，这一点需要注意。
当进行测试之后，测试的结果一定要给出一份报告出来。
是否通过压测要求？
最高的 QPS 是多少？
这样开发可以根据这份报告进行相应的优化。
提升性能的内容写一本书也不为过，这里简单罗列一些最常用的几点：
（1）慢 SQL
一般程序如果响应时间较长，可以首先看一下慢 SQL。
看下是否需要增加索引，或者进行 SQL 优化。
（2）缓存
针对查询，性能提升最显著的就是引入缓存。
当然，引入缓存会使架构变得复杂，这一点要结合自己的实际业务。
（3）硬件升级
如果程序优化的空间比较小，可以考虑升级一下硬件资源。
比如服务器配置翻倍，数据库配置翻倍。
什么？你说公司没钱升级？
没钱升级做什么压测？
这个时候测试报告的作用就显露了，直接用数据说话。
直接说 QPS 达不到生产要求，程序优化的空间很小，推荐硬件升级配置，升级到多少。
做人，要以德服人。
做测试，要用数据说话。
以德服人
测试最常用的工具当属 jmeter。
除此之外，还有一些其他的工具：
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面对几个工具做下简单介绍
Apache JMeter 可以用于测试静态和动态资源(Web动态应用程序)的性能。
它可以用于模拟服务器、服务器组、网络或对象上的负载，以测试其强度或分析不同负载类型下的总体性能。
将负载测试集成到开发工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
从12.55版本开始，您可以运行您的JMeter脚本，并在任何性能测试中集成JMeter和附加的脚本类型。
ps: 这个设计理念就非常好，可以和成熟的工具进行整合。站在巨人的肩膀上。
QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。
QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试，并针对所发现问题对系统性能进行优化，确保应用的成功部署。
ps: 这个工具本人没有接触过。
SilkPerformerV可以让你在使用前，就能够预测企业电子商务环境的行为—不受电子商务应用规模和复杂性影响。
可视化的用户化、负载条件下可视化的内容校验、实时的性能监视和强大的管理报告可以帮助您迅速将问题隔离，这样，通过最小化测试周期、优化性能以及确保可伸缩性，加快了投入市场的时间，并保证了系统的可靠性。
作为 DevOps 方法的一部分，IBM Rational Performance Tester 帮助软件测试团队更早、更频繁地进行测试。
它验证 Web 和服务器应用程序的可扩展性，确定系统性能瓶颈的存在和原因，并减少负载测试。
您的软件测试团队可以快速执行性能测试，分析负载对应用程序的影响。
ps: 这一款工具有 IBM 提供，质量值得信赖。
这么多工具可供使用，相信读到这里的小伙伴已经找到了自己心仪的测试工具。
别急，下面专门为做 java 开发的小伙伴们推荐一款性能测试工具。
男人有男人的浪漫，开发者当然也要有开发者的浪漫。
【男人的浪.jpg】
作为一名开发者，老马平时单元测试使用 junit 最多。
所以一直希望找到一款基于 junit 的性能压测工具，后来也确实找到了。
@JunitPerfConfig 指定测试时的属性配置。(必填项)
使用如下：
@JunitPerfRequire 指定测试时需要达到的要求。(选填项)
使用如下：
对应的测试报告生成方式也是多样的，也允许用户自定义。
基于控台日志：
或者基于 HTML:
junitperf
本文对性能测试做了最基本的介绍，让小伙伴们对性能压测有一个最基本的理解。
测试和开发一样，都是一件费时费力，而且需要认真做才能做好的事情，其中的学问不是一篇就能说清的。
性能测试工具也比较多，本文重点介绍了专门为 java 开发者打造的 junitperf 工具。
下一节我们将从源码角度，讲解一下 junitperf 的实现原理。
我是老马，期待与你的下次重逢。
开源地址：https://github.com/houbb/junitperf
java性能调试命令_性能测试--十个命令迅速发现性能问题
投机启示录
原创
关注
0点赞·85人阅读
十个命令迅速发现性能问题
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这是一种用来快速查看系统平均负载的方法，它表明了系统中有多少要运行的任务(进程)。在 Linux 系统中，这些数字包含了需要在 CPU 中运行的进程以及正在等待 I/O(通常是磁盘 I/O)的进程。它仅仅是对系统负载的一个粗略展示，稍微看下即可。你还需要其他工具来进一步了解具体情况。
这三个数字展示的是一分钟、五分钟和十五分钟内系统的负载总量平均值按照指数比例压缩得到的结果。从中我们可以看到系统的负载是如何随时间变化的。比方你在检查一个问题，然后看到 1 分钟对应的值远小于 15 分钟的值，那么可能说明这个问题已经过去了，你没能及时观察到。
在上面这个例子中，系统负载在随着时间增加，因为最近一分钟的负载值超过了 30，而 15 分钟的平均负载则只有 19。这样显著的差距包含了很多含义，比方 CPU 负载。若要进一步确认的话，则要运行 vmstat 或 mpstat 命令。
2. dmesg | tail
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.
这条命令显式了最近的 10 条系统消息，如果它们存在的话。查找能够导致性能问题的错误。上面的例子包含了 oom-killer，以及 TCP 丢弃一个请求。
千万不要错过这一步！dmesg 命令永远值得一试
3. vmstat 1
$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
vmstat(8) 是虚拟内存统计的简称，其是一个常用工具(几十年前为了 BSD 所创建)。其在每行打印一条关键的服务器的统计摘要。
vmstat 命令指定一个参数 1 运行，来打印每一秒的统计摘要。(这个版本的 vmstat)输出的第一行的那些列，显式的是开机以来的平均值，而不是前一秒的值。现在，我们跳过第一行，除非你想要了解并记住每一列。
检查这些列java系统性能测试：
rjava系统性能测试：CPU 中正在运行和等待运行的进程的数量。其提供了一个比平均负载更好的信号来确定 CPU 是否饱和，因为其不包含 I/O。解释：“r”的值大于了 CPU 的数量就表示已经饱和了。
free：以 kb 为单位显式的空闲内存。如果数字位数很多，说明你有足够的空闲内存。“free -m” 命令，是下面的第七个命令，其可以更好的说明空闲内存的状态。
si, so：Swap-ins 和 swap-outs。如果它们不是零，则代表你的内存不足了。
us, sy, id, wa, st：这些都是平均了所有 CPU 的 CPU 分解时间。它们分别是用户时间(user)、系统时间(内核)(system)、空闲(idle)、等待 I/O(wait)、以及占用时间(stolen)(被其他访客，或使用 Xen，访客自己独立的驱动域)。
CPU 分解时间将会通过用户时间加系统时间确认 CPU 是否为忙碌状态。等待 I/O 的时间一直不变则表明了一个磁盘瓶颈java系统性能测试；这就是 CPU 的闲置，因为任务都阻塞在等待挂起磁盘 I/O 上了。你可以把等待 I/O 当成是 CPU 闲置的另一种形式，其给出了为什么 CPU 闲置的一个线索。
对于 I/O 处理来说，系统时间是很重要的。一个高于 20% 的平均系统时间，可以值得进一步的探讨：也许内核在处理 I/O 时效率太低了。
在上面的例子中，CPU 时间几乎完全花在了用户级，表明应用程序占用了太多 CPU 时间。而 CPU 的平均使用率也在 90% 以上。这不一定是一个问题；检查一下“r”列中的饱和度。
4. mpstat -P ALL 1
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]
这个命令打印每个 CPU 的 CPU 分解时间，其可用于对一个不均衡的使用情况进行检查。一个单独 CPU 很忙碌则代表了正在运行一个单线程的应用程序。
5. pidstat 1
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
pidstat 命令有点像 top 命令对每个进程的统计摘要，但循环打印一个滚动的统计摘要来代替 top 的刷屏。其可用于实时查看，同时也可将你所看到的东西(复制粘贴)到你的调查记录中。
上面的例子表明两个 Java 进程正在消耗 CPU。%CPU 这列是所有 CPU 合计的；1591% 表示这个 Java 进程消耗了将近 16 个 CPU。
6. iostat -xz 1
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]
这是用于查看块设备(磁盘)情况的一个很棒的工具，无论是对工作负载还是性能表现来说。查看个列：
r/s, w/s, rkB/s, wkB/s：这些分别代表该设备每秒的读次数、写次数、读取 kb 数，和写入 kb 数。这些用于描述工作负载。性能问题可能仅仅是由于施加了过大的负载。
await：以毫秒为单位的 I/O 平均消耗时间。这是应用程序消耗的实际时间，因为它包括了排队时间和处理时间。比预期更大的平均时间可能意味着设备的饱和，或设备出了问题。
avgqu-sz：向设备发出的请求的平均数量。值大于 1 说明已经饱和了(虽说设备可以并行处理请求，尤其是由多个磁盘组成的虚拟设备。)
%util：设备利用率。这个值是一个显示出该设备在工作时每秒处于忙碌状态的百分比。若值大于 60％，通常表明性能不佳(可以从 await 中看出)，虽然它取决于设备本身。值接近 100% 通常意味着已饱和。
如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设备，则 100% 利用率可能只是意味着当前正在处理某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能能够处理更多的工作。
请记住，磁盘 I/O 性能较差不一定是程序的问题。许多技术通常是异步 I/O，使应用程序不会被阻塞并遭受延迟(例如，预读，以及写缓冲)。
7. free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
右边的两列显式：
buffers：用于块设备 I/O 的缓冲区缓存。
cached：用于文件系统的页面缓存。
我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O(使用 iostat 确认)，和更糟糕的性能。上面的例子看起来还不错，每一列均有很多 M 个大小。
比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些。Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它。所以部分被用作缓存的内存其实也算是空闲的内存。为了解释这一点， 甚至有人专门建了个网站： linuxatemyram。
如果你在 Linux 上安装了 ZFS，这一点会变得更加困惑，因为 ZFS 它自己的文件系统缓存不算入free -m。有时候发现系统已经没有多少空闲内存可用了，其实内存却都待在 ZFS 的缓存里。
8. sar -n DEV 1
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
这个工具可以被用来检查网络接口的吞吐量：rxkB/s 和 txkB/s，以及是否达到限额。上面的例子中，eth0 接收的流量达到 22Mbytes/s，也即 176Mbits/sec(限额是 1Gbit/sec)
我们用的版本中还提供了 %ifutil 作为设备使用率(接收和发送的最大值)的指标。我们也可以用 Brendan 的 nicstat 工具计量这个值。一如 nicstat，sar 显示的这个值是很难精确取得的，在这个例子里面，它就没在正常的工作(0.00)。
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
这是一些关键的 TCP 指标的汇总视图。这些包括：
active/s：每秒本地发起 TCP 连接数(例如，通过 connect())。
passive/s：每秒远程发起的 TCP 连接数(例如，通过 accept())。
retrans/s：每秒重传 TCP 次数。
active 和 passive 的连接数往往对于描述一个粗略衡量服务器负载是非常有用的：新接受的连接数(passive)，下行连接数(active)。可以理解为 active 连接是对外的，而 passive 连接是对内的，虽然严格来说并不完全正确(例如，一个 localhost 到 localhost 的连接)。
重传是出现一个网络和服务器问题的一个征兆。其可能是由于一个不可靠的网络(例如，公网)造成的，或许也有可能是由于服务器过载并丢包。上面的例子显示了每秒只有一个新的 TCP 连接。
10. top
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
top 命令包含了很多我们之前已经检查过的指标。可以方便的执行它来查看相比于之前的命令输出的结果有很大不同，这表明负载是可变的。
top 的一个缺点是，很难看到数据随时间变动的趋势。vmstat 和 pidstat 提供的滚动输出会更清楚一些。如果你不以足够快的速度暂停输出(Ctrl-S 暂停，Ctrl-Q 继续)，一些间歇性问题的线索也可能由于被清屏而丢失。
本文目录一览：
- 1、北大青鸟设计培训：Java初期学者程序性能容易的问题测试？
- 2、性能测试到底该怎么做？
- 3、java里测试添加的命令语句是什么
- 4、java各接口性能如何测试
- 5、北大青鸟java培训：解决WEB性能测试中的验证码问题？
北大青鸟设计培训：Java初期学者程序性能容易的问题测试？
1、介绍在开发中，性能测试是设计初期容易忽略的问题，开发人员会为了解决一个问题而“不择手段”，所参与的项目中也遇到了类似问题，字符串拼接、大量的调用和数据库访问等等都对系统的性能产生了影响，可是大家不会关心这些问题，“CPU速度在变快”，“内存在变大”，并且，“好像也没有那么慢吧”。
有很多商业的性能测试软件可供使用，如Jprofiler、JProbeProfiler等，但在开发当中显得有些遥远而又昂贵。
2、目标本文将讲述如何利用语言本身提供的方法在开发中进行性能测试，找到系统瓶颈，进而改进设计;并且在尽量不修改测试对象的情况下进行测试。
3、预备知识面向对象编程通过抽象继承采用模块化的来求解问题域，但是模块化不能很好的解决所有问题。
有时，这些问题可能在多个模块中都出现，像日志功能，为了记录每个方法进入和离开时的信息，你不得不在每个方法里添加log("insomemethod")等信息。
如何解决这类问题呢?将这些解决问题的功能点散落在多个模块中会使冗余增大，并且当很多个功能点出现在一个模块中时，代码变的很难维护。
因此，AOP(AspectOrientedProgramming)应运而生。
如果说OO(AobjectOrientedProgramming)关注的是一个类的垂直结构，那么AOP是从水平角度来看待问题。
动态代理类可以在运行时实现若干接口，每一个动态代理类都有一个Invocationhandler对象与之对应，这个对象实现了InvocationHandler接口，通过动态代理的接口对动态代理对象的方法调用会转而调用Invocationhandler对象的invoke方法，通过动态代理实例、方法对象和参数对象可以执行调用并返回结果。
说到AOP，大家首先会想到的是日志记录、权限和事务，是的，AOP是解决这些问题的好办法。
性能测试主要包括以下几个方面：计算性能：可能是人们首先关心的，北大青鸟http://www.kmbdqn.cn/认为简单的说就是执行一段代码所用的时间内存消耗：程序运行所占用的内存大小启动时间：从你启动程序到程序正常运行的时间可伸缩性(scalability)用户察觉性能(perceivedperformance)：不是程序实际运行有多快,而是用户感觉程序运行有多快.
性能测试到底该怎么做？
作为一名开发者，我们最长听到的就是编程界的三高：高性能、高并发、高可用。
听起来非常高大上，但是性能到底如何呢？又该如何评定呢？
这次我们谈一谈性能测试，看一看到底什么样才叫做高性能。
本文主要从以下几个方面进行讨论。
（1）性能测试是什么？
（2）为什么需要性能测试？
（3）性能测试如何做？
（4）有哪些性能测试的工具
老马曾经说过，你想理解一件事物，首先必须先定义它。
这里直接引用一下百科中的定义：
性能测试的定义也不难理解，往往定义本身阐述了性能测试的作用。
如果你是一名开发、测试，平时接手过不少需求，可能性能测试接触的也不多。
每一个需求，都有对应的功能性需求和肺功能性需求。
功能性需求是产品需求文档中最直接的，需要实现的功能目标。简称，能用就行。
非功能性需求则要宽泛的多，架构设计是否合理？是否便于后期拓展？是否便于监控？代码实现是否优雅？文档注释是否完整？
就像你写了一只鸟，鸟头做螺旋桨非能飞起来，但是在架构设计上可能是不合理的。
飞起来
一个查询功能，用户点击查询，10S 种才返回数据，功能上是满足的，但是性能上是不能接受的。
线上的交易功能平时各方面都很棒，节假日高峰期直接系统就瘫痪了。
那如何避免这些问题出现在生产上呢？
这就需要上线之前，首先做好对应的性能测试，避免再生产上出现问题，带来严重的生产事故。
性能要高，性能要硬，性能测试，又高又硬！
又高又硬
做一件事情之前，我们首先要确定好自己的目标。
性能测试，到底要测试什么？
有些类似于开发过程中的需求分析，常见的测试指标如下。
响应时间是指某个请求或操作从发出到接收到反馈所消耗的时间，包括应用服务器（客户端）处理时间、网络传输时间以及数据库服务器处理时间。
作为用户而言，在页面点击查询，等待了多久才能获取结果，这个就是响应时间。
用户不关心你后端经过了多少个服务，慢就是原罪。
对于微服务系统，链路监控就显得比较重要。可以帮助我们快速定位到底慢在哪里。
TPS（Transaction Per Second）是指单位时间（每秒）系统处理的事务量。
我看网上还有很多类似的概念：点击量/点击率、吞吐量/吞吐率、PV/UV，这里不做赘述。
个人看来本质上 TPS/QPS 就是去压测你应用的极限，当访问量较大的时候，程序能否活下来？
这里主要涉及到两个概念：高性能和高可用。
我们后面会简单讨论下这两点。
明确了测试指标之后，就需要进行测试的准备。
环境准备：比如你想压测数据库，那就需要准备对应配置的数据库资源。
脚本的准备：数据初始化脚本，调用脚本等。
这个可以类比开发过程中的代码开发。
ps: 性能压测一般不是很常用，所以环境准备流程会比较长，这一点需要注意。
当进行测试之后，测试的结果一定要给出一份报告出来。
是否通过压测要求？
最高的 QPS 是多少？
这样开发可以根据这份报告进行相应的优化。
提升性能的内容写一本书也不为过，这里简单罗列一些最常用的几点：
（1）慢 SQL
一般程序如果响应时间较长，可以首先看一下慢 SQL。
看下是否需要增加索引，或者进行 SQL 优化。
（2）缓存
针对查询，性能提升最显著的就是引入缓存。
当然，引入缓存会使架构变得复杂，这一点要结合自己的实际业务。
（3）硬件升级
如果程序优化的空间比较小，可以考虑升级一下硬件资源。
比如服务器配置翻倍，数据库配置翻倍。
什么？你说公司没钱升级？
没钱升级做什么压测？
这个时候测试报告的作用就显露了，直接用数据说话。
直接说 QPS 达不到生产要求，程序优化的空间很小，推荐硬件升级配置，升级到多少。
做人，要以德服人。
做测试，要用数据说话。
以德服人
测试最常用的工具当属 jmeter。
除此之外，还有一些其他的工具：
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面对几个工具做下简单介绍
Apache JMeter 可以用于测试静态和动态资源(Web动态应用程序)的性能。
它可以用于模拟服务器、服务器组、网络或对象上的负载，以测试其强度或分析不同负载类型下的总体性能。
将负载测试集成到开发工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
从12.55版本开始，您可以运行您的JMeter脚本，并在任何性能测试中集成JMeter和附加的脚本类型。
ps: 这个设计理念就非常好，可以和成熟的工具进行整合。站在巨人的肩膀上。
QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。
QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试，并针对所发现问题对系统性能进行优化，确保应用的成功部署。
ps: 这个工具本人没有接触过。
SilkPerformerV可以让你在使用前，就能够预测企业电子商务环境的行为—不受电子商务应用规模和复杂性影响。
可视化的用户化、负载条件下可视化的内容校验、实时的性能监视和强大的管理报告可以帮助您迅速将问题隔离，这样，通过最小化测试周期、优化性能以及确保可伸缩性，加快了投入市场的时间，并保证了系统的可靠性。
作为 DevOps 方法的一部分，IBM Rational Performance Tester 帮助软件测试团队更早、更频繁地进行测试。
它验证 Web 和服务器应用程序的可扩展性，确定系统性能瓶颈的存在和原因，并减少负载测试。
您的软件测试团队可以快速执行性能测试，分析负载对应用程序的影响。
ps: 这一款工具有 IBM 提供，质量值得信赖。
这么多工具可供使用，相信读到这里的小伙伴已经找到了自己心仪的测试工具。
别急，下面专门为做 java 开发的小伙伴们推荐一款性能测试工具。
男人有男人的浪漫，开发者当然也要有开发者的浪漫。
【男人的浪.jpg】
作为一名开发者，老马平时单元测试使用 junit 最多。
所以一直希望找到一款基于 junit 的性能压测工具，后来也确实找到了。
@JunitPerfConfig 指定测试时的属性配置。(必填项)
使用如下：
@JunitPerfRequire 指定测试时需要达到的要求。(选填项)
使用如下：
对应的测试报告生成方式也是多样的，也允许用户自定义。
基于控台日志：
或者基于 HTML:
junitperf
本文对性能测试做了最基本的介绍，让小伙伴们对性能压测有一个最基本的理解。
测试和开发一样，都是一件费时费力，而且需要认真做才能做好的事情，其中的学问不是一篇就能说清的。
性能测试工具也比较多，本文重点介绍了专门为 java 开发者打造的 junitperf 工具。
下一节我们将从源码角度，讲解一下 junitperf 的实现原理。
我是老马，期待与你的下次重逢。
开源地址：https://github.com/houbb/junitperf
java里测试添加的命令语句是什么
ava性能调试命令java性能调试命令_性能测试--十个命令迅速发现性能问题
投机启示录
原创
关注
0点赞·85人阅读
十个命令迅速发现性能问题
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这是一种用来快速查看系统平均负载的方法，它表明了系统中有多少要运行的任务(进程)。在 Linux 系统中，这些数字包含了需要在 CPU 中运行的进程以及正在等待 I/O(通常是磁盘 I/O)的进程。它仅仅是对系统负载的一个粗略展示，稍微看下即可。你还需要其他工具来进一步了解具体情况。
这三个数字展示的是一分钟、五分钟和十五分钟内系统的负载总量平均值按照指数比例压缩得到的结果。从中我们可以看到系统的负载是如何随时间变化的。比方你在检查一个问题，然后看到 1 分钟对应的值远小于 15 分钟的值，那么可能说明这个问题已经过去了，你没能及时观察到。
在上面这个例子中，系统负载在随着时间增加，因为最近一分钟的负载值超过了 30，而 15 分钟的平均负载则只有 19。这样显著的差距包含了很多含义，比方 CPU 负载。若要进一步确认的话，则要运行 vmstat 或 mpstat 命令。
2. dmesg | tail
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.
这条命令显式了最近的 10 条系统消息，如果它们存在的话。查找能够导致性能问题的错误。上面的例子包含了 oom-killer，以及 TCP 丢弃一个请求。
千万不要错过这一步！dmesg 命令永远值得一试
3. vmstat 1
$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
vmstat(8) 是虚拟内存统计的简称，其是一个常用工具(几十年前为了 BSD 所创建)。其在每行打印一条关键的服务器的统计摘要。
vmstat 命令指定一个参数 1 运行，来打印每一秒的统计摘要。(这个版本的 vmstat)输出的第一行的那些列，显式的是开机以来的平均值，而不是前一秒的值。现在，我们跳过第一行，除非你想要了解并记住每一列。
检查这些列java系统性能测试：
rjava系统性能测试：CPU 中正在运行和等待运行的进程的数量。其提供了一个比平均负载更好的信号来确定 CPU 是否饱和，因为其不包含 I/O。解释：“r”的值大于了 CPU 的数量就表示已经饱和了。
free：以 kb 为单位显式的空闲内存。如果数字位数很多，说明你有足够的空闲内存。“free -m” 命令，是下面的第七个命令，其可以更好的说明空闲内存的状态。
si, so：Swap-ins 和 swap-outs。如果它们不是零，则代表你的内存不足了。
us, sy, id, wa, st：这些都是平均了所有 CPU 的 CPU 分解时间。它们分别是用户时间(user)、系统时间(内核)(system)、空闲(idle)、等待 I/O(wait)、以及占用时间(stolen)(被其他访客，或使用 Xen，访客自己独立的驱动域)。
CPU 分解时间将会通过用户时间加系统时间确认 CPU 是否为忙碌状态。等待 I/O 的时间一直不变则表明了一个磁盘瓶颈java系统性能测试；这就是 CPU 的闲置，因为任务都阻塞在等待挂起磁盘 I/O 上了。你可以把等待 I/O 当成是 CPU 闲置的另一种形式，其给出了为什么 CPU 闲置的一个线索。
对于 I/O 处理来说，系统时间是很重要的。一个高于 20% 的平均系统时间，可以值得进一步的探讨：也许内核在处理 I/O 时效率太低了。
在上面的例子中，CPU 时间几乎完全花在了用户级，表明应用程序占用了太多 CPU 时间。而 CPU 的平均使用率也在 90% 以上。这不一定是一个问题；检查一下“r”列中的饱和度。
4. mpstat -P ALL 1
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]
这个命令打印每个 CPU 的 CPU 分解时间，其可用于对一个不均衡的使用情况进行检查。一个单独 CPU 很忙碌则代表了正在运行一个单线程的应用程序。
5. pidstat 1
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
pidstat 命令有点像 top 命令对每个进程的统计摘要，但循环打印一个滚动的统计摘要来代替 top 的刷屏。其可用于实时查看，同时也可将你所看到的东西(复制粘贴)到你的调查记录中。
上面的例子表明两个 Java 进程正在消耗 CPU。%CPU 这列是所有 CPU 合计的；1591% 表示这个 Java 进程消耗了将近 16 个 CPU。
6. iostat -xz 1
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]
这是用于查看块设备(磁盘)情况的一个很棒的工具，无论是对工作负载还是性能表现来说。查看个列：
r/s, w/s, rkB/s, wkB/s：这些分别代表该设备每秒的读次数、写次数、读取 kb 数，和写入 kb 数。这些用于描述工作负载。性能问题可能仅仅是由于施加了过大的负载。
await：以毫秒为单位的 I/O 平均消耗时间。这是应用程序消耗的实际时间，因为它包括了排队时间和处理时间。比预期更大的平均时间可能意味着设备的饱和，或设备出了问题。
avgqu-sz：向设备发出的请求的平均数量。值大于 1 说明已经饱和了(虽说设备可以并行处理请求，尤其是由多个磁盘组成的虚拟设备。)
%util：设备利用率。这个值是一个显示出该设备在工作时每秒处于忙碌状态的百分比。若值大于 60％，通常表明性能不佳(可以从 await 中看出)，虽然它取决于设备本身。值接近 100% 通常意味着已饱和。
如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设备，则 100% 利用率可能只是意味着当前正在处理某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能能够处理更多的工作。
请记住，磁盘 I/O 性能较差不一定是程序的问题。许多技术通常是异步 I/O，使应用程序不会被阻塞并遭受延迟(例如，预读，以及写缓冲)。
7. free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
右边的两列显式：
buffers：用于块设备 I/O 的缓冲区缓存。
cached：用于文件系统的页面缓存。
我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O(使用 iostat 确认)，和更糟糕的性能。上面的例子看起来还不错，每一列均有很多 M 个大小。
比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些。Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它。所以部分被用作缓存的内存其实也算是空闲的内存。为了解释这一点， 甚至有人专门建了个网站： linuxatemyram。
如果你在 Linux 上安装了 ZFS，这一点会变得更加困惑，因为 ZFS 它自己的文件系统缓存不算入free -m。有时候发现系统已经没有多少空闲内存可用了，其实内存却都待在 ZFS 的缓存里。
8. sar -n DEV 1
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
这个工具可以被用来检查网络接口的吞吐量：rxkB/s 和 txkB/s，以及是否达到限额。上面的例子中，eth0 接收的流量达到 22Mbytes/s，也即 176Mbits/sec(限额是 1Gbit/sec)
我们用的版本中还提供了 %ifutil 作为设备使用率(接收和发送的最大值)的指标。我们也可以用 Brendan 的 nicstat 工具计量这个值。一如 nicstat，sar 显示的这个值是很难精确取得的，在这个例子里面，它就没在正常的工作(0.00)。
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
这是一些关键的 TCP 指标的汇总视图。这些包括：
active/s：每秒本地发起 TCP 连接数(例如，通过 connect())。
passive/s：每秒远程发起的 TCP 连接数(例如，通过 accept())。
retrans/s：每秒重传 TCP 次数。
active 和 passive 的连接数往往对于描述一个粗略衡量服务器负载是非常有用的：新接受的连接数(passive)，下行连接数(active)。可以理解为 active 连接是对外的，而 passive 连接是对内的，虽然严格来说并不完全正确(例如，一个 localhost 到 localhost 的连接)。
重传是出现一个网络和服务器问题的一个征兆。其可能是由于一个不可靠的网络(例如，公网)造成的，或许也有可能是由于服务器过载并丢包。上面的例子显示了每秒只有一个新的 TCP 连接。
10. top
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
top 命令包含了很多我们之前已经检查过的指标。可以方便的执行它来查看相比于之前的命令输出的结果有很大不同，这表明负载是可变的。
top 的一个缺点是，很难看到数据随时间变动的趋势。vmstat 和 pidstat 提供的滚动输出会更清楚一些。如果你不以足够快的速度暂停输出(Ctrl-S 暂停，Ctrl-Q 继续)，一些间歇性问题的线索也可能由于被清屏而丢失。
java各接口性能如何测试
Java编程下用JMeter Java Sampler进行多接口性能测试，使用方法如下：
/**
*JMeter Java Sampler介绍
*setupTest做些初始化的工作，每个线程只执行一次
*teardownTest做些清理工作，每个线程只执行一次
*runTest具体的测试执行工作，每个并发每次循环都将执行一次
**/
//继承AbstractJavaSamplerClient
public class hessianTest extends AbstractJavaSamplerClient{
//hessian调用地址
private static String url = "hessian/remoting/userService";
MyService collect = null;
HessianProxyFactory factory = new HessianProxyFactory();
public int id;
@Override
public void setupTest(JavaSamplerContext arg0) {
//获取jmeter传入参数
id=arg0.getIntParameter("id");
try {
collect = (MyService) factory.create(
MyService.class, url);
} catch (MalformedURLException e) {
e.printStackTrace();
}
}
@Override
public SampleResult runTest(JavaSamplerContext arg0) {
SampleResult sp = new SampleResult();
sp.sampleStart();
User rt = null;
try {
rt = collect.getUser(id);
} catch (Exception e) {
sp.sampleEnd();
sp.setSuccessful(false);
return sp;
}
sp.sampleEnd();
if(rt.getId()==id)
sp.setSuccessful(true);
else
sp.setSuccessful(false);
return sp;
}
@Override
public void teardownTest(JavaSamplerContext context) {
super.teardownTest(context);
}
}
北大青鸟java培训：解决WEB性能测试中的验证码问题？
现在越来越多的网站为java系统性能测试了安全性或是防止Spam的侵害java系统性能测试，采用了验证码的校验技术。
简单地说java系统性能测试，验证码就是在进行登录或是内容提交的时候java系统性能测试，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串(一般是采用背景、扭曲等方式产生的图片)，要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。
但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。
已经不止一次有人提到这个问题，并询问有没有较好的解决方案。
对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。
这种方法最容易实现，对测试结果也不会有太大的影响(当然，这种方式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈)。
但这种方法有一个致命的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了;2、第二种方法，在第一种方法的基础上稍微进行一些改进。
第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。
这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较大的改进了;3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。
一般的性能测试工具(MI的LR、Seague的Silkperformer等)都能够调用外部的DLL或是组件接口，因此，广西电脑培训http://www.kmbdqn.cn/建议可以考虑获得“验证码验证”部分的实现，写一个验证码获取的DLL，在测试脚本中进行调用即可。
相关文章
发表评论
评论列表