Background
The project grew and grew, the number of users and may at any time request a blowout, and then wait until the remedy if the system crashes, a big loser, so you have to find a way to prevent in advance.
Want prevention, you have to know which ring system is relatively weak section, not stand the pressure, but also have a comprehensive assessment of the capacity of the system, the bottom of my heart, good to advance the prevention, such an assessment and a series of optimization analysis prevention It means all been covered, including performance testing.
Performance indicators
Different roles are not the same understanding of performance for the user, the operation is not smooth flow performance for R & D personnel, the interface does not slow slow and not hold up the top is the concurrent performance, for the operation and maintenance personnel, the network bandwidth size and resource consumption level is performance.
It is necessary to unify performance indicators, first of all, users and developers are concerned about the speed, processing speed of the interface is actually, then fine some client sends a request to receive the time returned from the server, then this indicator as response time now.
We do need is a product most users, the better, but with the increase in users and quantity, while initiating user operations more and more, the server may have to handle a sudden thousands of requests, in this the same time the number of requests processed is called concurrent, do not know when, high concurrency processing people become all in the eyes of the treasure, while the number of concurrent product has become a sign of bigger and stronger, so have the number of concurrent included index performance.
Only represent the number of concurrent requests at the same time a lot, but does not give too much meaning, people can not grasp the overall system profile when talking with others, so they need to be complicated by the number of variants to respond to different scenarios describe different services, such as how many people visit a day, one hour can handle the number of business, the number of transactions per second (TPS), HTTP requests per second (HPS), the number of queries per second (QPS) and so on, this indicator as we give it a name throughput.
In addition, but also to meet the requirements of operation and maintenance personnel, they need based on system load, memory usage, CPU usage, network disk I / O, and other indicators analyzed in order to prepare for the expansion of this series hardware indicators we referred to as performance counters.
Briefly explain the system load, which is the sum of the number of processes waiting to be executed CPU is currently executing, the number may reflect the system is busy, we most want to see is no process to wait in line, so the number is ideal load the number of CPU.
Four test types
我们在开发时会对系统的性能有个初步的预期，然后通过模拟请求程序逐步加大请求压力，直到你认为服务器资源的消耗已经无法接受了，此时再观察系统性能是否达到了预期，这种方式就是性能测试。注意，名称虽与上述重复但不是一个概念。
我们继续加大请求压力，直到服务器的某个资源已经达到饱和了，或者性能计数器中的某个指标达到了安全临界值，简单地说，再请求下去，系统的处理能力不但不能提高，反而会下降了。这种测试方式叫做负载测试。
还可以继续加大压力，不去管资源和性能指标如何，就疯狂请求，不停地请求，直到服务器崩溃，不能再继续工作了，这个时候就测出了系统最大承受能力，而这种测试方式被称为压力测试。
没办法再继续施压了，因为服务器已经没有响应，那就模拟一些比较真实的场景吧，因为真实场景下的请求压力是不均匀的，我们可以在特定环境、硬件和时间下给系统一定压力，看看业务是否能稳定运行，这种测试方式叫做稳定性测试。
优化手段
因为一个完整的WEB请求包含前端和后端两个部分，优化手段也从这两部分出发。
WEB前端优化
减少请求。现在大部分请求使用的是HTTP1，每个图片、脚本以及样式等资源的获取都要客户端单独跑线程建立连接，资源过多时消耗会很大，可以将不同类型的资源各整合至一个文件，这样少量的请求就能拿到需要的数据。
浏览器缓存。因为图片、脚本、样式等资源使用频率很低，没有必要每次请求都重新下载，可以通过设置HTTP的头部信息将资源缓存起来，这样可以有效降低加载速度，被缓存的资源需要更新时，可以通过修改资源文件名称的方式让浏览器重新下载。
压缩。图片、脚本、样式等静态资源一般都比较大，服务端可以将资源文件进行压缩，压缩后的文件较小，下载速度也会变快，但是前后解压缩文件会造成一定的压力，所以压缩手段要视业务情况而定。
CSS与JS顺序。因为浏览器会加载完所有的CSS后才去渲染页面，所以应该将样式文件放在上面加载。而JS刚好相反，浏览器刚加载完JS就会执行，如果放在前面会出现页面卡顿的现象，所以脚本文件应该放到页面最后加载。
CDN加速。原理与浏览器缓存类似，可以通过运营商将样式、脚本、图片等资源文件缓存到离用户最近的节点上，这样用户在发起请求时就能直接在最近的节点上找到需要的静态资源。
反向代理。在客户端与要交互的那台真实服务器中间再加一台服务器，所有的请求都由这台机器转发，当客户端第一次请求资源时将资源缓存到反向代理服务器，其他客户端就可以直接在反向代理服务器拿到资源，节省了转发的时间。
服务端优化
缓存。与前端一样，缓存是性能优化考虑的第一要素，目前流行的NoSQL数据库都是在内存读取的，速度会快，可以将读写频率很高但很少发生变化的数据放入缓存，可以有效提升系统吞吐量。
异步。像日志记录这种一定要去做但不需要等它做完的逻辑，应该把它放到消息队列当中，再由消费者进程逐条读取消息队列中的数据，慢慢执行，就像医院的排队取号，可以有效解决瞬时并发较大的业务场景。
集群。因为单台机器的处理能力有限，如果并发请求量过大，可能无法承受，可以加一些机器分担其压力，使得请求平均分配到每台机器上，这些由相同功能组成的机器群就是集群。
优化代码。不能秉着技术不够机器来凑的原则，回到实际代码当中来，多数性能问题还是代码写的不够优秀，比如三条语句能搞定的数据，查了十多条，几十行代码算出的变量，却没有地方使用，用不到的数据表联了又联等。
本文主要从概念和方法方面着手，意在科普知识，并没有实践案例，如果本文对你有帮助欢迎关注我们后续的文章。