Performance

http://blog.lifeibo.com/blog/2011/07/07/200-long-connection.html http://blog.yufeng.info/archives/1380

尽量将性能环境的以下参数调成跟生产环境一致： 1. 硬件 2. 网络 3. log日志级别 待续。。。

1. 请求的数据量大小（字节数) 2. 每秒请求数    a. 短连接应用：不必多说    b. 长连接应用：大量连接建立请求 3. 在线数    a. 短连接应用：Session数    b. 长连接应用：维持的长连接数(socket数) 4. 留存数据量： 数据库里已有的数据量 待续。。。

Numbers Everyone Should Know:

压力测试要测久一点才有意义。 有些系统指标，比如cpu load, 会随着测试的执行而逐渐变高。跑完60秒后发现单核load仍低于1就宣布压测通过，这是不对的。 那要在什么情况下才停止执行？　一般来说，可以等到系统指标稳定到一个值，或者系统指标超过了你心目中的安全权限（比如单核load>2)

收藏一个非常轻量的性能测试工具： http_load 它跟apache ab比较类似，但有个优点是可以接收多个URL作为测试输入，而不像apache ab那样，一次只能使用一个URL. 

互联网应用中，业务方最容易给出的评估指标是UV 我们就是要根据UV推导出系统应该具备的极限峰值 推导过程是：   1. 根据UV估计出PV，一般可以乘10   2. 确定峰值访问的时间长度（比如说中午那个小时），及这个时间段流量占全天流量的比例，从而得出这个时间段内的PV   3. 用这个PV数除于峰值时间段的跨度（单位秒），即得QPS 当然，QPS满足了要求未必就意味着性能达标了。你还要考虑并发数。经验上，可以使用25(当然未必普适)并发数作为极限并发数，然后再测一下在这个并发数QPS能否达到上面推导出的值。 p.s. 为了确定极限并发数，也可以逐渐提高并发数，依次进行性能测试；然后查看性能曲线(如qps，具体视情况而定)，直到性能曲线下降为止。

以下内容来自林昊的《分布式JAVA应用》 us高代表用户态程序占CPU的比例较高 sy高代表内核态程序占CPU的比例较高 对java应用来说， us高一般是因为    1. 有些线程一直处于可运行状态，比如使劲循环    2. CPU密集型操作太多，比如正则运算    3. 频繁GC sy高一般是因为线程上下文切换过于频繁。而切换过多，一般是由于过多阻塞导致的，包括锁等待、I/O阻塞等，一个线程的阻塞会导致CPU让另一个线程上位，即上下文切换。 p.s. sy高跟系统调用过多也会有关系

没有全部听懂，但有段关于latency的内容记住了：   1. 内存的latency：　纳秒级   2. 普通硬盘：　　　　毫秒级   3. Flash存储:      微秒级 也就是说，Flash存储的性能虽比不上内存，但比普通硬盘强太多了;　有的I/O密集型应用如数据库，如果对某些数据使用Flash存储，对性能的提升会非常明显。　

要解决的问题：并发能力没问题，但处理单个请求比较耗时，比如，获得一个统计值需要查多次数据库导致很长的响应时间   解决办法：      1.同步改异步，给用户的反馈也改成异步         前端程序把任务丢到后台消息队列后，立即告诉用户：“正在为你统计，请稍候刷新页面”         消息队列的消费者，即worker，在算出统计值后，再把结果丢进数据库         用户刷新页面时，前端程序去数据库查询到结果，再反馈给用户         这就叫异步计算         2.串行变并行，减少总体响应时间，用户可以同步等待反馈         把任务拆分成多个小任务，后台多个worker各领一个小任务并同时处理，响应时间立刻缩短         并行处理完后，再将结果合并起来，返回给用户         如果总体时间够短，对用户的反馈机制就没必要做成异步；用户可同步等等反馈          这叫做并行计算   具体技术：      1. 同步改异步：用消息队列，如MemcacheQ      2. 并行计算：采用Map/Reduce         a. Map代表拆分，Reduce代表汇总         b. 兼做监控、容错、可用性、负载均衡等事情         c. Map/Reduce框架本身不是开放的(Google的内部产品)，但思想是开放的；你可以用Hadoop来做Map/Reduce,　也可以自己编码实现