性能

主观视角:用户感受到的性能,与架构设计/UX设计有关.

客观视角:性能指标

在性能优化(设计重构)之前,不考虑性能要求或性能痛点,都是瞎做.

100并发对于一般系统并不少,在线用户可能上万,注册用户可达百万.不过对于电商网站来说还太少. 如双11时淘宝可达百万并发.

性能指标

响应时间,

并发数,在线用户数,系统用户数

TPS,QPS,HPS

吞吐量 = (1000/响应时间ms)*并发数

性能计数器:

System Load:CPU正在执行的线程+等待CPU执行的进程数之和.平均值为CPU核数较为理想.

对象与线程数,内存使用,CPU使用,磁盘与网络IO

性能测试

性能测试

负载测试

压力测试

稳定性测试

在C点很危险,因为系统处于奔溃边沿.

在B点左边可能性价比最高.

一般访问量呈波动状,因此压测时不应长时间进行相同负载的测试.

可能需要自已开发压测工具而不是使用通用压测公具.如基于Jmeter开发分布式压测平台.

全链路压测是必须的,也是难的.

性能优化

不能优化一个没有测试过的软件.

不能优化一个不了解的软件.

不是用了厉害的技术性能就好.



1. 软件性能优化

2. 软件架构优化

性能优化架构三板斧:缓存,异步,集群

优化架构前,请确保架构是有问题的.







3. 基础组件性能优化

悄无声息优化了性能节省了许多成本,最厉害了吧.但是可能跟采用各项新技术,新机器,新架构没任何关系,而只是简单的升级了下版本.

4. 操作系统优化

涉及了CPU,内存,进程,文件系统等



1) 进程

死的代码->有生命的进程->活动的进程(被CPU执行)

进程的状态

为了提高系统处理能力,在进程的基础上,引进了线程.

以超经典的tomcat为例 ,

Main函数执行时,起了一个JVM进程.

每一个请求发到80端口后,tomcat建立一个socket,并分配一个已初始化好的线程,用于持续监听此socket读请求数据,然后给应用程序(servelet)执行.

当用户不连续发请求或者网络差时,此线程就要阻塞了.因为一直在等待完整的数据进来以争夺CPU资源.阻塞很麻烦,想像,用户发1000个1个字节的请求之后,再也不动.结果服务器有1000个线程,占用了内存,却用不了CPU.很快内存满了,CPU在打盹,但系统奔溃了. 当然,有很多方式可以避免这种情况,比如设置超时,设置连接上限,检查请求大小,降级,熔断,使用异步方式处理请求等等.

除了要考虑如何协调各线程间的资源抢夺大战,还要考虑数据的线程安全性. 因为当某个线程要修改进程堆中的数据时,那么其他线程获得的数据可能就不一致了.于是,锁就用上了.将临界区的代码上锁.得锁者得控制权.值得单独讲一章.

2) 文件系统

B+树

LSM树

RAID

HDFS

多并发 - 性能优化的主要原因

1.传统守卫 - 锁(JVM与MYSQL)

2.新秀 - 异步(AKKA)