如何对日志服务器压力测试

1. 网站服务器如何做访问压力测试

网站服务器的压力测试我觉得主要有一些几点。
1.协议这边基本上以http或者https为主了，如果使用其他协议需要分析其打解包的方法。
2.要产生一定的压力，压力源这边一定要有保证。一般都是用机器人来模拟压力，关于机器人的逻辑可以根据具体业务来开发。
3.需要观察在一定压力下，服务器的各项性能指标（cpu，内存，IO，网络流量）进行观察，比如内存是否有泄漏，cpu利用率过高的情况。
4.压力测试应该是一个持续性的过程，在这个过程中需要统计服务器的性能数据，包括tps，以及机器的负载情况等。据此可以分析服务器的瓶颈在何处，后续可以针对优化。
5.目前大部分的服务器都部署在Linux系统上，测试同学还需要掌握相关的Linux命令以便可以更好的测试。
如果你觉得前面的太麻烦，可以来WeTest服务器压力测试高并发，实时性能报表，专家级性能优化建议，目前我们正在做网站压测这一块，你要做的仅仅是填下被测的URL即可，压力源、数据统计这些琐碎的工作交给我们就行了。

2. 想要进行服务器的压力测试有什么软件推荐一下

首先要是针对服务器压力测试（指的是服务器硬件的情况）的话，针对windows系统话可以通过批处理脚本进行压力测试，如果是liunx系统话可以通过ab测试工具进行测试。
如果针对web性能测试的话，可以通过loadrunner进行测试，网上的相关教程很多，书也有，学起来比较简单的

3. 求客户端（app）对服务器的压力测试怎么做，急急急！

性能测试就是压力测试，手机方面的其实和PC方面的差距不大，重点就是大量手机调用接口对服务器的压力，所以测试的重点还是在服务器上，你可以用Jmeter模拟接口报文，来并发压服务器，看服务器的响应和处理能力。单个手机毕竟是一个人在用，所以一般不用关心手机端的问题。手机端主要的就是功能没什么问题，只要app玩着玩着不要崩溃掉就行了.

4. 怎样测试服务器压力

下载并安装WAST；

1．设置并行连接数；

2．设置持续时间；

3．其余设置；

注：所有以上的选项可以根据自己的需要进行设置。

设置完成后就可以进行压力测试。测试的步骤如下：

第一步，点击工具栏上的“New Script”按钮，在打开的面板中点击“Nanual”按钮创建一个新的测试项目。在打开的窗口中对它进行设置，在主选项中的Server中填写要测试的服务器的IP地址。这里我们填写192.168.1.20。在下方选择测试的Web连接方式，这里的方式Verb选择get。Path选择要测试的Web页面路径，这里填写/Index.asp即动网的首页文件，WAST可以设置更多的Path。

第二步，在“Settings”功能设置中将Stress Level （Threads）线程数设置为1000。然后点工具中的灰色三角按钮即可进行测试。测试过程中我们可以从服务器的任务管理器中看到CPU使用率已经达到100%，损耗率达到最大。在CMD窗口中使用命令netstat -an，可以看到客户端的IP地址在服务器上的80端口进行了非常多的连接，而且Web网站已经打不开了，提示过多用户连接。

5. 集中式日志分析平台 - ELK Stack - Filebeat 压测

任何一款采集 agent 进行公司内全面推广前都需要进行性能测试以及资源限制功能测试，以保证：

对于 Filebeat 这款号称 golang 编写，性能强于 logstahs-forwarder 的采集 agent，我们也需要这样进行严谨对待。

硬件选择虚拟机，6cores + 16GB Mem + 175GB SSD + 1000Mbps 带宽；

Filebeat 配置，输出到 console：

Filebeat 配置，输出到 Kafka：

我们开启 Filebeat 的 6060 端口，并使用 python 脚本进行指标采集。
expvar_rates.py ，每秒统计出 Filebeat 指标，主要看：

Step1. 启动 Filebeat (172.16.134.8)

Step2. 启动统计脚本

Step3. 启动 tsar

Step4. 写入压测数据(6个进程写入，6千万条日志)

在 6 进程数据写入日志文件时，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.8 cores。
在 6 进程数据写入日志文件后，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 1.6 cores。
小结：

测试步骤和上述一致，区别在于配置文件需要输出到 Kafka。
在 6 进程数据写入日志文件时，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.7~0.8 cores。
在 6 进程数据写入日志文件后，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 2.0 cores。
小结：

测试步骤和上述一致，区别在于配置文件需要输出到 Kafka。
和上述步骤不同的是，启动 Filebeat 时需要 systemd 限制 CPU、句柄数，根据之前的理论，句柄数限制在 100 已经非常够用，CPU 限制在 1 core。
修改 /usr/lib/systemd/system/filebeat.service ：

执行 reload：

对 CPU 进行限制：

确认是否限制成功：

有如下输出表示OK：

在 6 进程数据写入日志文件时，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.7 ~ 0.8 cores。
在 6 进程数据写入日志文件后，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 1.0 cores，限制生效。
小结：

在 6 进程数据写入日志文件时，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.75 ~ 0.9 cores。
在 6 进程数据写入日志文件后，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 1.0 cores，限制生效。
小结：

在 6 进程数据写入日志文件时，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.7 ~ 0.75 cores。
在 6 进程数据写入日志文件后，我们在开启 python 统计脚本的窗口得到如下稳定的统计数据：

我们在 tsar 看到的统计数据为：

我们在 top 中可以看到 Filebeat 大致占据了 0.9 cores，未达到限制。
小结：

A. FB 全力采集 247B 数据(真实环境类似日志长度)，速率为 ~ 40K/s，CPU 开销为 2 cores；

B. FB 在 CPU 限制 1 cores 情况下，采集 247B 数据速率为 ~ 20K/s，可以认为单核采集速率为 ~ 20K/s/core；

C. 日志单行数据越大，吞吐越小，5KB 每行已经非常夸张，即使如此，没有压缩的情况下带宽消耗 35MBps，gzip 压缩率一般为 0.3~0.4，占用带宽为 10.5~14MBps，对于千兆网卡来说压力较小；

6. 如何对服务器进行压力测试

http_load是基于Linux平台的一种性能测工具。它是以并行复用的方式运行，仅适用于Web页面的性能测试，不适用于访问数据库，而且测试结果分析是有限的，平台依赖Linux 。http_load可以简单地通过txt文本文件中记录的参数来对HTTP服务器进行压力测试，那是如何对服务器进行压力测试的呢?下面我们就来介绍 Linux中如何安装使用http_load对服务器进行压力测试的教程。 具体方法步骤如下： 1、下载 官方网站：acme/software/http_load/http_load-12mar2006.tar.gz tar xzf http_load-12mar2006.tar.gz 2、安装 代码如下： cd http_load-12mar2006 make 执行完make，会在当前目录生成一个http_load二进制文件。 3、使用方法 代码如下： root@www：~/http_load-12mar2006# 。/http_load --help usage： 。/http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-timeout secs] [-sip sip_file] -parallel N -rate N [-jitter] -fetches N -seconds N url_file One start specifier， either -parallel or -rate， is required. One end specifier， either -fetches or -seconds， is required. 主要参数说明： -parallel 简写-p ：含义是并发的用户进程数。 -rate 简写-r ：含义是每秒的访问频率 -fetches 简写-f ：含义是总计的访问次数 -seconds简写-s ：含义是总计的访问时间 选择参数时，-parallel和-rate选其中一个，-fetches和-seconds选其中一个。 4、示例： 代码如下： http_load -parallel 50 -s 10 urls.txt 这段命令行是同时使用50个进程，随机访问urls.txt中的网址列表，总共访问10秒。 代码如下： http_load -rate 50 -f 5000 urls.txt 每秒请求50次，总共请求5000次停止。 测试网站每秒所能承受的平均访问量： 代码如下： http_load -parallel 5-fetches 1000urls.txt 这段命令行是同时使用5个进程，随机访问urls.txt中的网址列表，总共访问1000次。运行之后的结果： 1000 fetches， 5 max parallel， 6e+06 bytes， in 58.1026 seconds 6000 mean bytes/connection 17.2109 fetches/sec， 103266 bytes/sec msecs/connect： 0.403263 mean， 68.603 max， 0.194 min msecs/first-response： 284.133 mean， 5410.13 max， 55.735 min HTTP response codes： code 200 — 1000 从上面的运行结果来看，目标网站仅仅能够承受每秒17次访问，不够强壮。

7. 如何做压力测试

一个压力测试的流程：

1、明确测试目标

2、制定测试计划

3、实施测试，收集参数

4、分析测试结果

5、给出优化方案

一 、明确测试目标：如果是客户的需求，那需要向客户确认，有清楚的性能指标参数，测试时就是保证系统达到该指标并能良好运转，即压力测试。如果是自己的系统需要有一个评估，那就需要完整的得到该系统的几个临界点，拿到完整的性能曲线，从而来分析部署情况，即为性能测试。不管是哪个，知道了需求，才能制定计划。

性能测试的目标是发现重大的系统瓶颈。你可以想象一个系统由一系列的瓶颈组成；发现并改善一个瓶颈往往会在其他地方产生一个新的瓶颈。例如，我曾为一运行微软Windows CE的器件部门工作。我们发现的第一大性能问题体现在某一具体硬件环境下的内存管理中。我们把问题分离出来，改善了内存分配的效率。尔后再次运行我们的测试，又找到了一个新的瓶颈，这次体现在网络吞吐量上（throughput）。解决了这个问题后，我们接着又为下一个瓶颈改善而工作，然后再下一个，直到整个系统都达到了性能目标。要记住的是：关键在于要尽早订立性能目标，否则你可能不知道什么时候该停止性能测试。

二、制定测试计划：确定使用什么工具，着重哪些参数，设置线程数，方法执行次数，执行时间，是否多个接口同时进行测试等等。

三、实施测试，收集参数：选一个施压工具，来向部署好的服务发起高并发请求，同时关注和收集性能参数。这个是我们花费时间最多的地方。通常该阶段需要反复执行，来得到想要的数据。通常来说，我们可以使用JMeter LR AB 自己写多线程等各种方式，之后介绍一下JMeter。

四、分析测试结果：即根据上一节的参数介绍来进行参数分析。

五、给出优化方案：如果是代码逻辑耗费cpu，就优化算法；如果是redis等数据库耗时，就增加节点，减少读取，读写分离，使用内存等；如果是外在条件限制，则与外部们沟通问题，共同优化等等。

8. 游戏上线前服务器压力测试应该怎么做

对于游戏后台性能，评测标准不只单单是TPS（每秒处理多少个XX请求），因为当你的游戏服务器上线后，不存在一群玩家只发XX请求的压力场景。所以，游戏后台受到的现网请求压力永远是多场景混合的，在这样的压力下，后台能支撑多少人同时在线，才是一个游戏压测者需要得到的有价值的测试结论。
要得到可支撑的"最大同时在线人数"，主要做好2件事：
1、设计你的类现网压力模型
在现网真实压力里，不瞎卜论压力大小如何变化，现网环境如何变化，一个游戏类型和玩法设计定型后，永远有2个压力宏观数据保持不变：a. 各接口的压力比例不变， b.玩家平均每分钟操作频率不变。因此，压力测试目标就转变成了如何模拟符合ab数据的压力。
对于a，首先从同类型游戏或者本游戏内测阶段，日志插桩，收集各个接口的调用比例；然后，将接口比例转化为场景比例，如同时会有个2%完结登陆、15%玩家战斗余神粗、20%玩家拉取好友列表、10%玩家赌博（一个手游场景例子）。
对于b，同样在内测阶段收集玩家平均操作频率。
此时有了a和b，就可以构造出一分钟竖镇内玩家同时在线的真实压力模型了。
2、用压测工具构造出符合压力模型的压力
这个可以自己写，也可以使用现成的压测工具。现在市面上的压测工具很多，但很多都是专注于TPS这个参数，不符合游戏行业压测的关注点，同时在线人数。

9. 如何利用ApacheBench进行服务器压力测试

方法/步骤
1
比较常用的命令，如：
ab -n 请求数 -c 并发数 URL
2
跑了一个简单的Demo：
usertekiMacBook-Pro:~ zhaoxianlie$ ab -n 200 -c 10 http://127.0.0.1:8793/
This is ApacheBench, Version 2.3 <$Revision: 1554214 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.jinbanz.com/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8793

Document Path: /
Document Length: 28012 bytes

Concurrency Level: 10
Time taken for tests: 6.847 seconds
Complete requests: 200
Failed requests: 0
Total transferred: 5665503 bytes
HTML transferred: 5601103 bytes
Requests per second: 29.21 [#/sec] (mean)
Time per request: 342.343 [ms] (mean)
Time per request: 34.234 [ms] (mean, across all concurrent requests)
Transfer rate: 808.07 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 148 338 93.2 335 633
Waiting: 148 337 93.3 335 633
Total: 148 338 93.2 336 634

Percentage of the requests served within a certain time (ms)
50% 336
66% 371
75% 397
80% 413
90% 461
95% 500
98% 568
99% 610
100% 634 (longest request)
3
这其中Requests per second、Time per request算是裤举大家都比较看重的两个评估参数了吧。
不过对于这种压力测试来说，也不能一上来就 -n 1000 -c 10，还是得慢慢来，一开始可以来一个 -n 50 -c 10这样子，逐渐网上增加，取Request per second的最大值作为Http server的性能指标，应该会靠谱一些。
假设我的这个测试服务器RPS峰值是30，那一分钟能扛过来的请求差不多 1800 个，这是单核CPU的情况下。
假设是我厂服务器的配置，24核，开启Node的cluster模式，RPS应该是此橘倍数增加的，明胡扒碧天去公司找台服务压测一把。如果真是这样，那么每秒钟能扛过来的请求差不多 720 个，换算到一个小时，是259.2w个访问请求。
假设服务器配置是Nginx+Node，Nginx做负载均衡，proxy_pass对应的upstream配置到4台Node服务器，且每台Node服务器均衡负载，那么，一个小时能扛得动的流量基本是 1kw多一些，满负荷跑一天，2.4亿的流量了。