转:Tsung 环境搭建

 参考:https://blog.csdn.net/anndy_/article/details/120366681

Tsung运行环境安装

检查安装一下依赖包,以免在安装的时候报错.(操作系统的软件包完全安装时，这些包通常都会装进去，所有也可以跳过，此步骤，后面遇到问题时，少哪包再装哪个包，逐个解决。)

rpm -qa build-essential openssl openssl-devel unixODBC unixODBC-devel make gcc gcc-c++ kernel-devel m4 ncurses-devel

1

每个包系统盘或者镜像中都有。

安装 erlang、gnuplot、perl5

• erlang ：因为Tsung是基于erlang开发的,所以得先安装这个环境.安装软件
• perl5：生成报表的脚本支持环境
• gnuplot：报表统计图片生成工具
• libtemplate-perl: 生成报表所需的画图模板库

erlang安装

admin@iZa:~$ sudo yum install erlang

设置环境变量以便下一步安装Tsung时使用

admin@iZa:~$ export PATH=$PATH:/usr/local/erlang/bin/

验证erlang是否安装成功

admin@iZa:~$ erl

​​

gnuplot、perl5、libtemplate-perl安装

admin@iZa:~$ sudo yum install perl5 gnuplot libtemplate-perl

验证安装后的版本

admin@iZa:~$ perl –v 

admin@iZa:~$ gnuplot

Tsung安装

1、到官网下载安装包 http://tsung.erlang-projects.org (最新版本为1.7.0)

admin@iZa:~$ sudo wget http://tsung.erlang-projects.org/dist/tsung-1.7.0.tar.gz

2、解压缩安装包

admin@iZa:~$ sudo chmod 777 tsung-1.7.0.tar.gz

admin@iZa:~$ sudo tar zvxf tsung-1.7.0.tar.gz 

3、编译安装

admin@iZa:~$ cd tsung-1.7.0/

admin@iZa:~/tsung-1.7.0$ sudo ./configure --prefix=/usr/local/tsung

admin@iZa:~/tsung-1.7.0$ sudo make

admin@iZa:~/tsung-1.7.0$ sudo make install

4、验证是否安装成功，先做个软连接方便使用tsung命令

admin@iZa:~$ sudo ln -s /usr/local/tsung/bin/tsung /usr/bin/  

admin@iZa:~$ tsung

转:进程优先级，进程nice值和%nice的解释

 https://blog.csdn.net/qq_44222849/article/details/105802672

【popexizhi:这里对NI和%nice 很清晰，赞！

总结一下，优先级是进入cpu前的队列 权限；而Nice是单位时间cpu分片给你的个数，前者是排号先后，后者是可以都给你的资源，维度不一致；优先级是插队，而nice是排队后供应的内容可以多给你的量，你有优先级，是认识管理排队的人，排队前后走后门；而nice可是认识买东西的，买的时候直接多给你啊！！！ 不过两者好像都有用，资源有限时，你就是nice在低，排队靠后，当轮到你时就没有可以买给你的了吧？！再想想，这里的资源是时间片，逻辑上应该是没有耗尽的，所以nice一定有用的！：）

】

用top或者ps命令会输出PRI/PR、NI、%ni/%nice这三种指标值，这些到底是什么东西？先给出大概的解释如下：

PRI ：进程优先权，代表这个进程可被执行的优先级，其值越小，优先级就越高，越早被执行

NI ：进程Nice值，代表这个进程的优先值

%nice ：改变过优先级的进程的占用CPU的百分比 （呵呵，这句好难理解是吧，不急慢慢来_）[popexizhi: 从下面的例子上看，这里可以理解为， 对一个进程单位时间，系统最多可以给你 两个进程的时间片-20，至于你定义多少NI一定在这个范围，而%nice 是你计划多要的/可以多给你的-20 比例 ]

PRI是比较好理解的，即进程的优先级，或者通俗点说就是程序被CPU执行的先后顺序，此值越小进程的优先级别越高。那NI呢？就是我们所要说的nice值了，其表示进程可被执行的优先级的修正数值。如前面所说，PRI值越小越快被执行，那么加入nice值后，将会使得PRI变为：PRI(new)=PRI(old)+nice。由此看出，PR是根据NICE排序的，规则是NICE越小PR越前（小，优先权更大），即其优先级会变高，则其越快被执行。如果NICE相同则进程uid是root的优先权更大。

在LINUX系统中，Nice值的范围从-20到+19（不同系统的值范围是不一样的），正值表示低优先级，负值表示高优先级，值为零则表示不会调整该进程的优先级。具有最高优先级的程序，其nice值最低，所以在LINUX系统中，值-20使得一项任务变得非常重要；与之相反，如果任务的nice为+19，则表示它是一个高尚的、无私的任务，允许所有其他任务比自己享有宝贵的CPU时间的更大使用份额，这也就是nice的名称的来意。

进程在创建时被赋予不同的优先级值，而如前面所说，nice的值是表示进程优先级值可被修正数据值，因此，每个进程都在其计划执行时被赋予一个nice值，这样系统就可以根据系统的资源以及具体进程的各类资源消耗情况，主动干预进程的优先级值。在通常情况下，子进程会继承父进程的nice值，比如在系统启动的过程中，init进程会被赋予0，其他所有进程继承了这个nice值（因为其他进程都是init的子进程）。

对nice值一个形象比喻，假设在一个CPU轮转中，有2个runnable的进程A和B，如果他们的nice值都为0，假设内核会给他们每人分配1k个cpu时间片。但是假设进程A的为0，但是B的值为-10，那么此时CPU可能分别给A和B分配1k和1.5k的时间片。故可以形象的理解为，nice的值影响了内核分配给进程的cpu时间片的多少，时间片越多的进程，其优先级越高，其优先级值（PRI）越低。%nice，就是改变过优先级的进程的占用CPU的百分比，如上例中就是0.5k/2.5k=1/5=20%。

由此可见，进程nice值和进程优先级不是一个概念，但是进程nice值会影响到进程的优先级变化。

进程的nice值是可以被修改的，修改命令分别是nice和renice。

1、nice命令就是设置一个要执行command进程的nice值，其命令格式是 nice –n adjustment command command_option，如果这里不指定adjustment，则默认为10。

2、renice命令就是设置一个已经在运行的进程的nice值，假设一运行进程本来nice值为0，renice为3后，则这个运行进程的nice值就为3了。

说明：如果用户设置的nice值超过了nice的边界值（LINUX为-20到+19），系统就取nice的边界值作为进程的nice值。

举例如下：

对非root用户，只能将其底下的进程的nice值变大而不能变小。若想变小，得要有相应的权限。

[oracle@perf_dbc ~]$ nice
1

0

[oracle@perf_dbc ~]$ nice -n 3 ls
1

agent bin important_bak logs statistics_import.log TMP_FORUM_STATS.dmp TMP_TAOBAO_STATS.dmp TMP_TBCAT_STATS.dmp top.dmp worksh

[oracle@perf_dbc ~]$ nice -n -3 ls
1

nice: cannot set priority: Permission denied

对root用户，可以给其子进程赋予更小的nice值。

[root@dbbak root]# nice
1

0

[root@dbbak root]# nice -n -3 ls
1

192.168.205.191.txt anaconda-ks.cfg clariion.log Desktop disk1 emc.sh File_sort install.log install.log.syslog log OPS rhel_os_soft root_link_name

同样，renice的执行也必须要有相应的权限方可执行。

Get-Process-powershell

参考:

https://forsenergy.com/zh-cn/windowspowershellhelp/html/27a05dbd-4b69-48a3-8d55-b295f6225f15.htm

进程的默认显示为包括以下列的表：

-- Handles：进程打开的句柄数。

-- NPM(K)：进程正在使用的非分页内存量，以千字节为单位。

-- PM(K)：进程正在使用的可分页的内存量，以千字节为单位。

-- WS(K)：进程工作集的大小，以千字节为单位。工作集包括进程最近引用的内存的页面。

-- VM(M)：进程正在使用的虚拟内存量，以兆字节为单位。虚拟内存包括磁盘上分页文件中的存储。

-- CPU(s)：进程已用于所有处理器的处理器时间量，以秒为单位。

-- ID：进程的进程 ID (PID)。

-- ProcessName：进程的名称。

https://www.starky.ltd/2019/02/26/windows-powershell-cookbook-1/

结构化命令（Cmdlets）

PowerShell 引入了一种名为 Cmdlets 的新型命令。所有的 cmdlets 命令都以 Verb-Noun 的形式命名，如 Get-Process、Get-Content、Stop-Process 等。

1 2 3 4 5 6 7 8 9

PS C:\Users\starky> Get-Process -Name chrome Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName ------- ------ ----- ----- ----- ------ -- ----------- 285 36 80040 93808 620 104.61 1384 chrome 201 16 9000 7296 121 0.05 3572 chrome 1061 73 57324 99924 550 145.21 4052 chrome 221 17 8864 7952 131 0.08 5832 chrome 260 30 209528 154748 534 118.55 6408 chrome

spotlight-windows

 

https://www.cnblogs.com/AmilyWilly/p/9012558.html

downlod: 

下载 https://pan.baidu.com/s/1qYi3lec 
Spotlight大家可以从其官方网站(http://www.quest.com/spotlight-on-windows/)下载

　　Authorization Key：295713336449229168750

　　Site Message：Bergelmir/CORE

APDEX(Application Performance Index)

jmeter 4.0  的报告首页包含apdex值，很奇怪，go了一下，如下:

Apdex 评估标准

（http://developer.51cto.com/art/201408/447814.htm）

在网络中运行的任何一个应用（Web、数据库、E-mail等等），它的响应时间决定了用户的满意程度。那么这个“响应时间”是什么？是一个请求数据包得到响应的时间吗？不，这样一个孤立的响应时间再短对用户来说也毫无意义。举一个Web应用的例子，当用户进行一次http链接时，客户端和服务器之间会产生很多个交互（一个交互指一次客户端的请求和服务器的响应），而不是只有一个。可以想象缺少了这其中的任何一个交互，打开的网页都是残缺不全的，http链接这一动作产生的所有交互完成之前，用户无法进行下一步的操作。

换一个角度来看这个过程，进行http链接是用户使用Web应用时发生的一个任务（Task），只有这个任务完成，用户才能进行下一个任务（再次进行http链接，或下载文件等等）。用户在网络上使用一个应用的过程，就是发生连续的一系列任务的过程。

任务的概念非常重要，它是应用性能和用户体验的结合点。在完成一个任务之前，用户是在等待其完成才行下一个任务，这个等待时间片的长短直接影响了用户对应用的满意程度。这才是对用户有真正的意义的“响应时间”，Apdex把完成这样一个任务所用的时间长短称为应用的“响应性”。

基于“响应性”，Apdex定义了3个用户满意度区间: [popexizhi: 这个区间的默认是定义为T的，T的基础值是可以设置的，下面例子是默认值 ]

满意: 这样的响应时间让用户感到很愉快，例如少于3秒钟。
容忍: 慢了一点，但还可以接受，继续这一应用过程，例如3～12秒。
失望: 太慢了，受不了了，用户决定放弃这个应用，例如超过12秒。

“满意”、“容忍”、“失望”这三个区间通过响应时间数值“T”来划分，T值代表着用户对应用性能满意的响应时间界限或者说是“门槛”（Threshold），也就是第一个区间“满意”的底线，如3秒，满意区间就是0~3秒；响应时间超过T值用户就有些不满了，下一个区间“容忍”的界限值则是T和4T，即3~12秒之间为容忍区间；响应时间再长用户就开始考虑放弃了，最后一个区间“失望”的响应时间则大于4T，即多于12秒。

之后，Apdex对应用中发生的任务进行采样，并且按其响应时间把采样划分到相应的满意度区间，计数，再用一个公式计算Apdex指数：
实际上，这个公式的意义在于：
一个满意样本得分为：1
一个容忍样本得分为：0.5
一个失望样本得分为：0
因此公式也可以写成：
Apdex指数 ＝（1 × 满意样本 ＋ 0.5 × 容忍样本）÷ 样本总数
这样，采样结果被量化为一个0到1之间的数值即“Apdex指数”，0代表没有满意用户，1则代表所有用户都满意。经过统计，Apdex把这个数值与用户满意程度细化对应，如下图所示，对于应用性能的Apdex评分与用户的体验紧密关联，为管理者提供了一种通过应用性能量化值来评估用户满意度的方法。
（https://blog.csdn.net/qq_27791709/article/details/78393804）

官网介绍

http://www.apdex.org/

[next]

可以测试的其他内容
WildPackets的著名的抓包软件Omnipeek (https://zhuanlan.zhihu.com/p/47746909)

转:go 基线测试

https://www.flysnow.org/2017/05/21/go-in-action-go-benchmark-test.html


[popexizhi： 原文的例子确实不错，测试了一下，感觉这个应该是函数/方法级别的很好用，可以用于方法对比的评估中。]

什么是基准测试

基准测试，是一种测试代码性能的方法，比如你有多种不同的方案，都可以解决问题，那么到底是那种方案性能更好呢？这时候基准测试就派上用场了。

基准测试主要是通过测试CPU和内存的效率问题，来评估被测试代码的性能，进而找到更好的解决方案。比如链接池的数量不是越多越好，那么哪个值才是最优值呢，这就需要配合基准测试不断调优了。

如何编写基准测试

基准测试代码的编写和单元测试非常相似，它也有一定的规则，我们先看一个示例。

itoa_test.go

func BenchmarkSprintf(b *testing.B){
 num:=10
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  fmt.Sprintf("%d",num)
 }
}

这是一个基准测试的例子，从中我们可以看出以下规则：

1. 基准测试的代码文件必须以_test.go结尾
2. 基准测试的函数必须以Benchmark开头，必须是可导出的
3. 基准测试函数必须接受一个指向Benchmark类型的指针作为唯一参数
4. 基准测试函数不能有返回值
5. b.ResetTimer是重置计时器，这样可以避免for循环之前的初始化代码的干扰
6. 最后的for循环很重要，被测试的代码要放到循环里
7. b.N是基准测试框架提供的，表示循环的次数，因为需要反复调用测试的代码，才可以评估性能

下面我们运行下基准测试，看看效果。

➜  hello go test -bench=. -run=none
BenchmarkSprintf-8      20000000               117 ns/op
PASS
ok      flysnow.org/hello       2.474s

运行基准测试也要使用go test命令，不过我们要加上-bench=标记，它接受一个表达式作为参数，匹配基准测试的函数，.表示运行所有基准测试。

因为默认情况下 go test 会运行单元测试，为了防止单元测试的输出影响我们查看基准测试的结果，可以使用-run=匹配一个从来没有的单元测试方法，过滤掉单元测试的输出，我们这里使用none，因为我们基本上不会创建这个名字的单元测试方法。[popexizhi: 这个-run=none 在pope本地的效果好像没什么不一样]

下面着重解释下说出的结果，看到函数后面的-8了吗？这个表示运行时对应的GOMAXPROCS的值。接着的20000000表示运行for循环的次数，也就是调用被测试代码的次数，最后的117 ns/op表示每次需要话费117纳秒。

以上是测试时间默认是1秒，也就是1秒的时间，调用两千万次，每次调用花费117纳秒。如果想让测试运行的时间更长，可以通过-benchtime指定，比如3秒。

➜  hello go test -bench=. -benchtime=3s -run=none
BenchmarkSprintf-8      50000000               109 ns/op
PASS
ok      flysnow.org/hello       5.628s

可以发现，我们加长了测试时间，测试的次数变多了，但是最终的性能结果：每次执行的时间，并没有太大变化。一般来说这个值最好不要超过3秒，意义不大。

性能对比

上面那个基准测试的例子，其实是一个int类型转为string类型的例子，标准库里还有几种方法，我们看下哪种性能更加。

func BenchmarkSprintf(b *testing.B){
 num:=10
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  fmt.Sprintf("%d",num)
 }
}

func BenchmarkFormat(b *testing.B){
 num:=int64(10)
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  strconv.FormatInt(num,10)
 }
}

func BenchmarkItoa(b *testing.B){
 num:=10
 b.ResetTimer()
 for i:=0;i<b.N;i++{
  strconv.Itoa(num)
 }
}

运行基准测试，看看结果

➜  hello go test -bench=. -run=none              
BenchmarkSprintf-8      20000000               117 ns/op
BenchmarkFormat-8       50000000                33.3 ns/op
BenchmarkItoa-8         50000000                34.9 ns/op
PASS
ok      flysnow.org/hello       5.951s

从结果上看strconv.FormatInt函数是最快的，其次是strconv.Itoa，然后是fmt.Sprintf最慢，前两个函数性能达到了最后一个的3倍多。那么最后一个为什么这么慢的，我们再通过-benchmem找到根本原因。

➜  hello go test -bench=. -benchmem -run=none
BenchmarkSprintf-8      20000000               110 ns/op              16 B/op          2 allocs/op
BenchmarkFormat-8       50000000                31.0 ns/op             2 B/op          1 allocs/op
BenchmarkItoa-8         50000000                33.1 ns/op             2 B/op          1 allocs/op
PASS
ok      flysnow.org/hello       5.610s

-benchmem可以提供每次操作分配内存的次数，以及每次操作分配的字节数。从结果我们可以看到，性能高的两个函数，每次操作都是进行1次内存分配，而最慢的那个要分配2次；性能高的每次操作分配2个字节内存，而慢的那个函数每次需要分配16字节的内存。从这个数据我们就知道它为什么这么慢了，内存分配都占用都太高。

[popexizhi: 这里的-benchmem，在本地测试的版本中为-test.benchmem ，我的测试版本是go1.11.4， 可能与原文的版本有出入吧:) ]

在代码开发中，对于我们要求性能的地方，编写基准测试非常重要，这有助于我们开发出性能更好的代码。不过性能、可用性、复用性等也要有一个相对的取舍，不能为了追求性能而过度优化。

转:[Linux 性能调优] 网卡中断与CPU的绑定问题

https://www.cnblogs.com/bamanzi/p/linux-irq-and-cpu-affinity.html

1.监控终端数量

mpstat -P ALL 1 的输出中查明：里面的 %irq一列即说明了CPU忙于处理中断的时间占比

18:20:33     CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
18:20:33     all    0,23    0,00    0,08    0,11    6,41    0,02    0,00   93,16   2149,29
18:20:33       0    0,25    0,00    0,12    0,07    0,01    0,05    0,00   99,49    127,08
18:20:33       1    0,14    0,00    0,03    0,04    0,00    0,00    0,00   99,78      0,00
18:20:33       2    0,23    0,00    0,02    0,03    0,00    0,00    0,00   99,72      0,02
18:20:33       3    0,28    0,00    0,15    0,28   25,63    0,03    0,00   73,64   2022,19

上面的例子中，第四个CPU有25.63%时间在忙于处理中断（这个数值还不算高，如果高达80%（而同时其它CPU这个数值很低）以上就说明有问题了），后面那个 intr/s 也说明了CPU每秒处理的中断数（从上面的数据也可以看出，其它几个CPU都不怎么处理中断）。

然后我们就要接着查另外一个问题：这个忙于处理中断的CPU都在处理哪个（些）中断？

2.查看中断数量

[popexizhi：动态变动监控方式:watch -d "cat /proc/interrupts|sed 's/        /,/g'|sed 's/ //g'"]

cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
  0:        245          0          0    7134094    IO-APIC-edge  timer
  8:          0          0         49          0    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
 66:         67          0          0          0   IO-APIC-level  ehci_hcd:usb2
 74:     902214          0          0          0         PCI-MSI  eth0
169:          0          0         79          0   IO-APIC-level  ehci_hcd:usb1
177:          0          0          0    7170885   IO-APIC-level  ata_piix, b4xxp
185:          0          0          0      59375   IO-APIC-level  ata_piix
NMI:          0          0          0          0 
LOC:    7104234    7104239    7104243    7104218 
ERR:          0
MIS:          0

这里记录的是自启动以来，每个CPU处理各类中断的数量（第一列是中断号，最后一列是对应的设备名）[详细说明: E.2.10 /proc/interrupts - Deployment Guide - RedHat Enterprise Linux 6 )，从上面可以看到： eth0所出发的中断全部都是 CPU0在处理，而CPU0所处理的中断请求中，主要是eth0和LOC中断。（有时我们会看到几个CPU对同一个中断类型所处理的的请求数相差无几（比如上面的LOC一行），这并不一定是说多个CPU会轮流处理同一个中断，而是因为这里记录的是“自启动以来”的统计，中间可能因为irq balancer重新分配过处理中断的CPU——当然，也可能是谁手工调节过）