1.压力测试的理解，xxx的性能10w/s，对你有意义么？
没有那家卖瓜的会说自己家的不甜，同样，没有哪个开源项目愿意告诉你在对它条件最苛刻的时候压力情况是多少，一般官网号称给你看的性能指标都是在最理想环境下的，毫无参考意义。
举个栗子,Redis官网压测的例子，256字节的读速度11w/s,写速度8.1w/s,都知道redis优点是多变的数据结构，string、List、hash、set、sortset，实际工作稍微复杂的环境往往都是各种结构混合使用，字符串长度各异，你需要的是真正在你的工作环境下，即：你混合使用的数据结构下，你的访问压力下，你的字符串长度下redis的x响应性能。这个值往往跟官方公布的差异很大。我的经验，我们是视频行业，相对字符串长度较长，在压缩序列化之后，主要使用String和List，性能在访问client=200-400左右，qps相应能到5w，超过这个client值，qps下降而且服务器负载上扬，容易引起服务器雪崩效应，这个5w，才是真正基于我们业务使用下redis的性能瓶颈。
我这个服务压力2000tps,你觉得很牛逼？
看着很牛逼对不对，好像tps值越高显得能力越强一样，其实很可笑，如果性能好只是比这个，那写一个1+1=2的程序估计是无敌了吧。具体问题要具体分析，你牛逼你要说明你牛逼在哪里，在什么条件下，什么样子的背景，才能说你的tps是多少，这样才有意义。
反正线上没出现过问题,我们撑得住，你确定？
线上没出现过问题，不代表流量不会增加，流量不会增加不代表业务不会复杂，业务复杂性能下降是很有可能的，没有压力测试做保证，出问题就是大问题。
压力测试都是qa在做，有问题会反馈给我，你的服务极限到底在哪里？
压测不是玩笑，你的4个9的指标呢
好的服务都会有一项指标，叫4个9，即99.99%得服务可靠性。这是衡量一个服务是否优秀的普世标准，压力测试的好坏最直观的影响4个9的保障。压力测试就是用来确保服务的稳定，给出服务稳定极限条件。稳定指的是服务负载，cpu利用率，接口的响应时长，网络的延迟，结果准确性等等都在你的标准之内。而这些指标又相互影响。
条件，用尽量多的已知去推测未知，模拟仿真，你要做的预测未来
硬件条件:服务器cpu核数、内存大小、网络条件、同宿主机下其他服务影响，软件条件:虚拟访问用户数、gc的稳定程度，响应时长要求，第三方依赖的可用程度、jdk的不同版本等都会严重影响压力测试的结果，造成你的压测结果上线之后达不到逾期。如果这些条件不注意，很可能你压测时按照达标条件tps=1000，其实线上tps才500的时候，服务已经崩溃了。压测的时候，最好保障压测环境与线上一致。你的结果才更有意义。
3.你想要的到底是个什么东西
tps只是结果，虚拟用户数，线程数，平均响应时长，错误数，90%的平均响应时长，服务器负载，结果准确性尽量用越来越多的点来评估你的服务。
tps：服务处理的吞吐量，每秒响应请求的数量，tps是压力测试最直观的结果，是衡量服务性能的一个结果性指标，一般说压力测试性能值就是tps值。最浅显直白的理解，统计access日志每秒的总数就是那一秒的tps值。
错误数：一般服务压力测试的时候是不允许出现错误的，即错误数:0%,但是复杂条件下，有的服务是允许出错率不超过x%的，看服务而定。
结果准确性：多线程下访问下结果的正确性。这个在压测的时候往往容易被忽略。这个需要你在压力测试的时候抽查访问接口，查看结果是否正确，曾经碰到过qa测试通过的接口，上线之后发现返回结果不正确，内网回测正确，后来内网压力测试的时候成功复现，是由于使用了不安全的多线程代码导致的，其实压测的时候抽查看一眼，很容易看出来。
线程数：这个指标不在各大压力测试工具监控之内，但是这其实是压力测试非常重要的服务指标。根据经验，好多时候服务崩掉的时候，线程数已经满了，好多时候应用服务器的线程在某个范围之内，服务是最健康的状态，超过某个范围，服务处于不稳定状态，处于有点网络抖动延迟都容易崩溃的临界点，所以熟悉这个值，你就心里清楚你的服务当前在什么状态下。
多说一句，这个值为什么又可以不去管它：其实真正线上流量大的时候经常会有一种现象：服务直接重启撑不起来当前流量，调整前端流量分配(部分nginx摘除重启server等做法),慢慢启动就可以支持起线上流量，再打开所有流量，发现server又可以支持没问题了(ps:所以nginx有一个流量缓增的收费模块就是干这个的)，但是慢慢启动线上流量和一次打过来线上流量，其实在同一时刻虚拟用户数是差不多，斯以为这种现象是因为服务刚启动时流量全打过来时需要创建的可复用复用对象和线程很多，容易造成了服务的不稳定，那么其实压力测试时虚拟用户数重要么？它真的是不可代替的么？其实虚拟用户数只是用来探测服务性能的一个表现的总结而已，服务真正的健康情况其实反映在线程数，响应时长，服务器负载，性能瓶颈点(比如事务或者锁)等等，而虚拟用户数只是这些健康极限情况的表象总结而已。就是说，当压力测试总结的虚拟用户数在某一个范围值tps达到多少，其实内在真正描述的是在这个虚拟用户时，由于线程数是多少，负载是多少，平均相应时长是多少，线程数是多少，gc稳定程度是多少达到了tps值是多少。
4.面试总问的jvm调优到底是要干什么？
5.常用的压力测试工具及命令
loadrunner，jmeter，自写jar包，tcpcopy等。
jmap，jstack，jstat，详细的讲解推荐《深入理解java虚拟机》，其实不神秘但是特别实用，jstat查看内存回收概况，实时查看各个分区的分配回收情况，jmap查看内存栈，查看内存中对象占用大小，jstack查看线程栈，死锁，性能瓶颈，某个线程使用cpu过高导致服务整体慢等都可以通过在这些命令辅助Linux命令看出来。
top，vmstat,sar,dstat，traceroute，ping，nc，netstat，tcpdump，ss等等具体请百度。
你的服务是跑在linux系统上的,是依赖第三方服务出问题了？是受别的服务影响还是自己利用资源过高？是网络抖动了？是网卡满了么？是cpu性能不够么？是写入磁盘瓶颈了？内核数据交换频繁？负载变高了？都需要linux命令才能看出来。
6.性能诊断到底难在哪里？
收到服务报警了，怎么办？打印的log日志都是连接不上memcache，难道是memcache的问题，手动客户端连接memcache没问题，难道是网络的问题，测试网络延迟很低，那到底怎么了？
其实服务类似于人体，有的人感冒的时候鼻子通气嗓子疼，有的人头疼，有的人流清涕，有的人流黄涕，对症下药要治标治本。没有什么统一的答案，这就体现了经验的重要性。举个栗子：某天晚上突然收到报警，vpn登陆发现服务还正常返回，暂时没有报错，但是负载明显升高，resin线程数飙升到1000多(正常情况下该服务高峰期线程数500-700)，cpu使用率偏高，排查:1.访问量激增？统计发现并没有。2.网络状况异常？通过访问服务器发现也没有，稍微慢些是因为负载稍高。3.程序有瓶颈打印内存栈线程栈都没发现4.受其他同宿主服务影响？查看监控发现并没有。仔细观察发现流量稍有波动但是不明显。为什么负载高呢？最后排查发现是前端nginx带宽满了，带宽拥堵造成代理的后端服务无法及时返回数据，后端服务的句柄数拥堵造成服务器负载升高，服务器负载升高又使线程数和cpu利用率升高，造成服务的个别访问响应时长过长，触发报警。再严重些估计就会造成连接memcache超时，log打出连接memcache错误的日志。蝴蝶效应而已。想要快速抓住重点，其实跟医生一样，就需要你对服务足够了解，平时多关心服务状态而且经验真的很重要。
7.到底是加机器还是优化服务？
成本，加机器是一种成本，优化服务也是一种成本，很有可能你的服务很多依赖第三方，推动他们符合你的要求也是一种沟通成本，很多时候，老板的思路永远在于成本，如果他认为服务有很大的优化空间，那你找他加机器他多半是不会同意的，所以这种要资源的事情，请考虑成本，也有一个问题，大公司往往会哭的才有奶吃，这也很现实，反正归根到底，对于我们这些搞服务端的来说，成就感不就应该是把硬件服务器资源压榨到底么。