• 前言
• 先考虑一些问题
• 压力源
• 服务器资源记录和监控
  • 服务器配置信息
  • 服务器实时资源信息
  • Netdata
• 性能调优
• 后记
• Ref

前言

以前只是知道开发要写单元测试，顶多就是接口测试，而对压测只是停留在知道的程度(其实还有一个疲劳测试，就是长时间地加压)，直到最近有了某个接口的压测需求，才开坑压测，本来想着稍微学学，满足需求即可，但是没想到压测已经是一门学问，要了解和学习的东西并不只是所看到的冰山一角

先考虑一些问题

1.理解性能? –理发店模式
2.QPS和TPS以及一些测试指标和模型的理解?
3.期望如何?比如并发量多少?吞吐(Throughput)和延迟(Latency)多少?
–网页延迟就是500ms,因为超过这个时间人的注意力会分散 ref: http://www.cnblogs.com/ioriwellings/p/4582043.html
4.如何布置压测拓扑? 压测机配置? 被压测机部署? –压测一般压30分钟

压力源

　　说到压力源，就是模拟用户的地方，因为不太可能用真的成千上万的人力去并发请求一个接口，所以就有很多模拟用户并发的测试工具，比如ab,wrk,jmeter,loadRunner或者是现在公司用的locust,中文名是蝗虫，其实可以发起网络请求的都可以做压测，所以我见过有用curl或者python的requests库做压测的，但是还是比不上专用的压测工具，为什么呢？这是因为一方面专用的压测工具本身就打包了很多压测过程中会用到的特性，另一面，压测工具对于压测机单机资源利用程度比较高，就拿locust来说，基于协程的设计让他的压力产生在所有的压测工具中脱颖而出，这也是公司选择locus的原因之一，就同等的机器，locust能模拟更多的并发
P.s.参考估计:一台双核4G的机器，locust能模拟600-1000的用户并发

服务器资源记录和监控

我原本以为只要学习locust就知道怎么压测了，但是没想到的是locust只是压，如果不去记录被压机硬件配置和观察压力下的被压机的资源状况，只会用locust是没有什么效果的，locust只是从用户的角度看问题，顶多算是个黑盒测试，locust只能获取调用接口的成功数，失败数，每秒请求量，接口最高并发量等，但是对于测出最高并发量没有达到预期要求的情况，这明显就是不够的，所以就要看看服务器资源在被压力源施压下的变化，这就需要一些服务器资源搜集工具了
我这里就直接以linux为前提了，其实linux很多系统资源信息都在/proc这个目录下，而比如lscpu,vmstat这些个命令其实也是基于/proc这个目录提供的信息进一步包装的，所以你如果熟悉linux和C/C++的话，完全可以按照自己的需求根据/proc写一套自己的系统资源搜集套件～

服务器配置信息

CPU: lscpu
Memory: free -h
Disk: df -h
Network: ifconfig
OS: lsb_release -a 或者 uname -a

服务器实时资源信息

linux获取资源实时信息有一堆的命令，简直看到眼花，但是我今天总结了一天，其实发现实用的就几个，htop/top,dstat,netstat
htop是top的升级版，能用htop就用htop，top毕竟太老，有很多特性不支持，比如移动选择进程，直接在界面杀掉进程等，而且htop界面很漂亮，尽管top是原生带有的不用安装，但是还是在你的server上装一个htop吧
dstat则是vmstat, iostat and ifstat的合集，一般都是直接用dstat -cdlmnpsy以获取更多的信息
netstat提出来主要是看TIME_WAIT等连接状态的统计,着重网络方面异常的发现

P.s.特别要注意数据库性能方面,这个要单独拿出来讲，比如mysql，可以查看相关variable和status值，还可以打开慢查询记录，分析一些慢查询语句等(数据库性能方面相对有点复杂，待补充…)

Netdata

上面的是手动一个个去看CPU，内存，磁盘，IO等资源状况，那么对于我们分析性能而言，其实更加希望的是这些资源状况信息的一个汇集，那么netdata就是这么一个工具，而且它资源占用极少(甚至开了KSM以后还能再节省40-60%的内存资源)，dashboard的界面酷炫，并且它是实时的!虽然保存不便，但是实时这点对我们分析实在帮助很大，所以也就不计较保存的不便了，有志者可以提PR改进netdata的保存数据的功能哈
当然，除了做压测以外，本身netdata就可以做服务器资源监控和报警，这个是和一些云服务的监控类似，而基于netdata本身提供的RESTful api，我们又可以重新定制这些监控数据，简直不能再好～
P.s.netdata还能接入比如redis,mysql,postgresql,rabbitMQ,kafka,nginx等常见应用的监控

性能调优

根据上面得出的信息和压测报告，我们可以知道我们的服务是不是有性能问题，而且有了对系统资源以及服务进程对资源消耗占比，我们就可以开始针对性的调优以达到我们预想的性能指标(e.g.可承载用户并发数)，而关于性能调优这方面，又可以从系统设计的多个层次维度来分别调优，比如从网关，中间件，业务逻辑，数据库等等，说起服务性能调优可以说是一匹布那么长，这里就不展开篇幅了，有兴趣的可以自行慢慢研究，或者等以后我不定期更新，哈哈

后记

测试应该是QA的内容，这让我想起来之前写过docker和git效率工作一文中说到的DevOps，那时候的理解只是停留在Dev开发和Ops运维上，因为那时候是基于docker来看的，但是后面看到一些文章以后，DevOps其实还包含了QA，更加应该说在DevOps这个概念流行之前，在开发过程中测试的思想就已经很普遍了，因为测试是开发唯一的信心来源，所以DevOps的概念应该是Dev+QA+Ops,当然如果自动化基础设施和工具不完善，一个人根本做不到DevOps，所以如果要做到DevOps，那么对自动化的要求就要十分高，比如自动化部署(CI/CD)，自动化测试(回归/压力/疲劳)，自动化监控报警等等

Ref

1.腾讯Wetest服务器测试课程
2.perf & valgrind
3.虫师博客——《Web接口开发自动化测试》一书作者