性能测试流程
cpu有无瓶颈的标准：
uptime命令看系统平均负载，看cpu核数，cpu看负载值小于核数属于合理，多于核数会有排队现象，排队范围是否能接受
uptime -V用来查询版本的
1.当前时间：16:44:20
2.系统已运行的时间：6:49
3.当前在线用户：2 users
4.平均负载：0.04,0.01,0.00，最近1分钟，5分钟，15分钟系统的负载
/proc/uptime文件里包含两个数值，如下图：
第一个数值代表系统总的启动时间，第二个数值则代表系统空闲的时间，都是用秒来表示的。如果系统里第二个数字比第一个数字还要大，则说明你的cpu是多核的，cpu0上闲了一秒，cpu1上闲了两秒，加起来就是三秒
内存有无瓶颈的标准：
没用内存泄露，GC(垃圾回收机制)合理，不要看内存使用率
io有无瓶颈的标准：
iostat -x 命令，看IO队列在合理范围内await或者在nmon里看DISKBUSY超过20%，磁盘有问题，IO是指磁盘的读写操作
network有无瓶颈的标准：
用sar或netstat命令查看是否丢包，是否有错误率或在nmon里看net
中间件里都有压缩，压缩等级越高，效果越好，不过性能损耗也越大，resin(apache下的一款工具)和tomcat一样，F5是收费的，其他都是免费的
apache和tomcat都是web服务器，两者既有联系又有区别，apache是web服务器(静态解析，如html)，tomcat是java应用服务器(动态解析，如jsp)，tomcat只是一个servlet(jsp也翻译成servlet)容器，可以认为是apache的扩展，可以独立运行
1、两者都是apache组织开发的
2、两者都有http服务的功能
3、两者都是开源免费的
a、apache是普通服务器，本身只支持html即普通网页，可以通过插件支持php，还可以与tomcat连通(apache单向连接tomcat，就是说通过apache可以访问tomcat资源，反之不然)
b、apache只支持静态网页，但像jsp动态网页就需要tomcat来处理
c、apache和Tomcat整合使用：
如果客户端请求的是静态页面，则只需要apache服务器响应请求
如果客户端请求动态页面，则是tomcat服务器响应请求，将解析的jsp等网页代码解析后回传给apache服务器，再经apache返回给浏览器端
这是因为jsp是服务器端解析代码的，tomcat只做动态代码解析，apache回传解析好的静态代码，apache+tomcat这样整合就可以减少tomcat的服务开销
d、apache和tomcat是独立的，在同一台服务器上可以集成，因为jsp需要连接数据库的话就要jdk来提供连接数据库的驱动，所以要运行jsp的web服务器平台就需要apache+tomcat+jdk
apache和nginx的相同点：在功能实现上都使用了模块化结构设计，都支持通用的语言接口，如php、perl、python等，同时也支持正向、反向代理，虚拟主机，URL重写等
apache的优点：
1、更稳定
2、rewrite模块更完善
3、模块众多，基本想到的都可以找到
4、少bug ，nginx的bug相对较多
nginx的优点：
1、轻量级，相对apache占用更少的内存和资源
2、因为nginx是非阻塞型的，高并发下能保持低资源低消耗，因此更适合做高并发
3、配置简洁
4、nginx负载均衡服务器(最好的负载均衡服务器)，支持10万并发
负载均衡也叫代理转发，包括反向代理和正向代理，大部分是反向代理，负载均衡访问的是apache这个端口，落在不同的tomcat上，nginx也一样
appBase工程路径webapps
流量漏斗原理：就是从上层到底层的流量会越来越少
zookeeper是同一用户中心的意思，在zookeeper的服务里注册会员(所有接口)、商品(所有接口)、订(所有接口)，按照接口注册，不按照节点注册，注册完别人可以调用接口，进入zookeeper要配置生产者和消费者，生产者就是配置这些接口，配置这些人，在配置消费者，谁消费这些接口，谁可以调用这些接口，再配置一层权限
dubbo是分布式系统，把一个大的系统划分成小的节点，减低系统的耦合度，更加灵活，一个节点(会员节点)挂了不影响别的节点(商品节点或其他)，节点之间没有影响
kafka是消息队列的意思，和mq一样，mq收费，kafka是开源的，首先是保证消息一致性，都能收到消息，第二是请求的顺序，一条一条取，消息不会乱，如果增加一个会员直接写到kafka里，其他节点直接从kafka里读出新增的会员信息，群聊就相当于kafka
redis是缓存，一定要保证缓存的高命中率，查询量大的数据放到redis里，如果缓存命中率低，没必要访问redis，直接访问mysql就行
把图片放在图片服务器上，图片放在cdn里，就近去取图片，下载速度快
把文件放在文件服务器上
Web容器需要关注的三点：
第一点是线程池，所有中间件都要关注线程池或进程池，是否太小，小了可以加，是否太大，太大了可以减，是否排队，理解配置参数的意义
第二点是timeout时间，可以设置连接apache和tomcat的长连接时间
第三点是压缩等级，gzip压缩是否开启，对哪些内容进行压缩
面试最常问到的是性能测试流程：
a、了解系统基本架构和业务流程
了解系统基本架构是做架构评审，从架构上发现哪个地方有点设计问题，是否在这个架构上有性能的改进或者是说这个架构用了哪些以前我不知道的新技术，我需要进行学习，还有就是为了方便监控各个数据流环节，从而不会遗漏性能瓶颈点，这是我了解系统架构的原因
了解业务流程其实就是了解数据流程，请求流程，不关心业务，只关心数据流转
b、性能测试环境需求获取以及确定
1、开发过程相关文档
2、相似项目性能需求
性能测试目标的获取有两种途径，一是已有系统的升级改造，或者是公司类似项目的性能测试，二是这个公司是新成立的公司，或者这个业务是一个全新的业务方向
3、业界公认标准
2/5/8，引导开发人员
4、80/20原则
5、系统日志
为什么做日志分析呢？
以前做测试的时候性能测试目标都是开发或产品人员直接给出来的，性能测试场景也是开发或业务人员给出来的，给出来之后就会出现各种各样的问题，性能需求达不到要求，开发就会无限降级，降到一个比较低的目标之后在上线，上线之后可能就出问题，出现问题之后大家就会进行推诿，开发或产品把问题推给测试，测试人员也会把责任推给开发，开发定的目标，比较痛苦，烦这一块，性能测试目标是开发，运维或产品给出的，因为我们不了解业务逻辑，只能照做，做完之后就会经常出现一些场景遗漏的情况，有哪个场景没有做性能测试，上线之后会出性能故障，比如内存泄露，数据库响应很慢，把系统压挂等等，会出现这些事故，因为场景是开发人员给出的，测试人员是执行的，造成很尴尬的事情，发生这种情况之后又会有扯皮推诿的现象，我很烦这种情况，我觉得真正的性能测试不应该是这样，所以我要改变这种情况，所以引入了日志分析系统，从日志分析系统里面获取当前系统的top10，50 ，100都可以，当前系统访问量最高的场景是哪些，以及这些场景平均响应时间，最大响应时间是多少，我们都可以在日志系统里进行获取，从日志系统里可以直接拿出做系统的场景设计，基础数据可以拿到，单场景数据可以拿到，加入综合场景以及混合性场景，这样我们的目标，并发和响应时间可以从日志系统分析获取到，并发数和响应时间可以初步定出来，至少系统在升级改造或换代，那么这些功能或是响应时间可以定，至少不能比日志分析的并发和响应时间少，目前是满足性能需求的，不能越改造越烂，场景不会有遗漏，性能测试目标也定出来，不会有降级的事情出现，必须最低限度满足这个要求，性能降级也不会出现，所有人必须尊重日志分析系统，在出事就是测试的事，开发和产品必须严格遵循日志分析的结果，那么这种扯皮和推诿现象就会减少
c、性能测试场景获取以及用例设计
1、用户量访问比较大的功能，应该优先纳入性能测试场景
2、与金钱相关比较重要的场景，应该优先纳入性能测试场景
3、影响业务主流程的场景，应该优先纳入性能测试场景
4、开发人员认为可能存在性能问题的场景，应该优先纳入性能测试场景
5、应该考虑综合场景，防止线程争用导致线程死锁以及数据库死锁
6、应该做稳定性场景测试，防止长时间运行导致内存泄漏情况发生
d、性能测试环境的准备与搭建
这里还没有完成
对一个项目做性能测试，需要了解的信息
1、找项目负责人或者开发问时间安排(项目什么时候上线，性能测试什么时候开始、什么时候测完)，如果是IOS APP，server端上线之后不影响，还可以改动，APP本身第一次上线(提交审核)之后就不要改了
2、如果不是全新的项目而是以前项目的升级改造，找PM确认哪些地方需要做性能测试、性能测试目标是什么，然后自己再做二次确认，如果有日志分析(监控日志、分析日志)的话，判断PM提出的性能指标是否合理(新、旧指标相比较，以苛刻的为准)，从日志分析里找出升级之后对老的功能有没有影响，如果有影响则该场景也要加入到需要测试的功能中
如果是全新的项目，找产品经理确认哪些场景需要做测试及性能测试目标，找产品经理、运维、开发等做数据量确认(容量预警)、并发增量确认
3、找运维了解系统架构，线上硬件配置、软件版本，申请测试环境和资源，搭建测试环境
4、搭建测试环境，申请和线上一样的环境
压力测试这么实现，下面两个红框只能选择一个，要么选择持续时间，要么选择第二个
资源不充足时，申请3台和线上一模一样的硬件作为web服务器，申请一台跟负载均衡一样的做负载均衡服务器
性能无损的情况下，先测试一台Web服务器支持100并发，乘以线上服务器的台数，测试两台Web服务器支持200并发，有可能有性能损耗，如果两台最好并发数是198，性能损耗率是1%，测试三台Web服务器支持300并发，有可能有性能损耗，如果三台的并发数是294，性能损耗率是2%，相对准确的估算
并发数的确定，pv换算，80-20原则，某个时间段内秒时刻的峰值日志三种方式，一般2000并发就可以了，最大并发数和最佳并发数，响应时间和TPS记录下来
并发数=PV/(PV统计的时间，换算成s，一天是86400s)*(页面连接次数，包括外部的js css图片等，一般可用10)*(http响应时间，一般可用1秒或更少)*(因数，一般用5)/web服务器数量，简化得出并发数=PV/1728*web服务器数量
测试报告的书写：
首先把测试结论放在前面
发现什么问题，解决什么问题放在第二
优化建议放在第三个
后面在写详细的测试报告
为什么要拆库分表？
减小单表数据量，提高数据库执行效率，解决数据量大的问题
分库分表规则
---按号段分
以user_id为基准，1-1000对应DB1,1001-2000对应DB2
---hash取模分
user_id%4，可以比较均匀的把数据放在4个数据库里，等下次登录时在和4取模，最常用
Oracle单表数据量2000万，oracle数据库拆成mysql：
拆库分表校验什么东西？
1.id split规则校验
2.完整性校验(old总=拆总 old0101总=拆0101总 old0808总=拆0808总，挨个表校验总数)
3.分院帽(规则，性能，异常)
4.字符集(字符集不同，oracle的是gbk，mysql的是utf8)
5.列与列对不对，错列，少列，串列
6.ID补全
7.表无遗漏
8.字段类型(数据类型不同，oracle是int(256),mysql是int(4)，还有integer类型)
pv峰值是一天中24*60*60，最大的一秒的值
线上性能监控和预警(运维监控工具)
cacti
nagios
zabbix
响应时间的预警两个维度：趋势和阀值(超过响应时间的比例)
增量计算
容量规划包括两点：
1.数据库增量
2.趋势一个计算
在开发和产品人员给出的做增量计算，增量计算进行上线
首页、跳转页、所有和钱相关的也要做性能测试，场景和目标完了之后，让开发人员加场景，加个增量，场景操作哪些数据库，涉及到哪些表，加数据量
未来容量规划
先对一台机器进行能力评估，比如，评测结果为该服务器支撑动态请求1000个/s，支持静态流量400MB/s
预估动态支撑
1小时有96万次页面刷新，每个页面刷新包括1-3个动态请求
预估目前并发数=(960000*3)/(1*3600)=800个/s
按照未来峰值并发大概为目前的10倍进行扩展，则800个/s*10=8000个/s
而单台服务器支撑动态请求为1000个/s，则8000/1000=8，故初步预估未来需要8台服务器支撑动态请求容量
预估静态支撑
预计每个页面包括的image，js，css大约为50个左右的静态文件，每个文件大约为40KB
预计目前带宽=960000次/(1*3600s)*50*40/1024/1024=0.5GB/s
预计未来流量峰值可能达到5GB/s左右(按10倍进行扩展)，则5/(400/1024)=13，400M/s是已知的，故初步预估未来需要13台服务器支撑静态请求容量，静态走网络带宽流量
