引子
公元1800年前，一代枭雄曹操此时已经病入膏肓。曾经征战四方，挟天子以令诸侯、筑铜雀以显四海之威名的曹操躺在病床上再也忍受不了头疼欲裂的痛苦。
此时的曹操只能无力的从病榻上伸出惨白的手颤抖和无力的在空中挥舞着，他用尽全身最后一点力气呼喊道“华陀呢。。。叫华陀。。。华陀在哪。。。叫华陀呀”，而持卫所能贡上的却只有华陀的人头
：”报丞相，华陀己被斩首“
：”啊。。。这，这。。。啊。。。“
一代枭雄就此丧命！
《三国演义》第七十八回：治风疾神医身死，传遗命奸雄数终
操即差人星夜请华佗入内，令诊脉视疾。
佗曰：“大王头脑疼痛，因患风而起。病根在脑袋中，风涎不能出，枉服汤药，不可治疗。某有一法：先饮麻肺汤，然后用利斧砍开脑袋，取出风涎，方可除根。”
操大怒曰：“汝要杀孤耶！”
佗曰：“大王曾闻关公中毒箭，伤其右臂，某刮骨疗毒，关公略无惧色；今大王小可之疾，何多疑焉？”
操曰：“臂痛可刮，脑袋安可砍开？汝必与关公情熟，乘此机会，欲报仇耳！”
呼左右拿下狱中，拷问其情。
贾诩谏曰：“似此良医，世罕其匹，未可废也。”
操叱曰：“此人欲乘机害我，正与吉平无异！”急令追拷。
这是一篇写给技术人员同时也是写给PM、产品经理、IT业务部门主管看的文章
第一章 华陀给曹操疾病的预警想到系统性能问题
曹操，得的是绝症。
绝症，一开始并非是绝症。
华陀其实给了曹操三次“风险预警”，最后曹操非担未接受反以怨报德杀了华陀，此时曹操的病己经深入了骨髓，因此就再也无法医治了，等待他的只有死亡的命运
这和我们曾经遇到过的为了快速响应、满足企业的业务需求、网站的快速迭代需求而疏忽了代码质量、系统性能而导致的结果是多么的相像。
当系统的第一版本上线时，技术一般为了满足业务的需要会选择在性能或者是在安全和代码质量上做出一定的让步。
当系统上线后，又为了满足业务的快速变化，技术也会选择一些让步
而当业务量上来时，嘿嘿，前面的两次让步已经积累成了“深入骨髓”的病变，此时还可以治即“开颅”手术，而往往在这时，笔者所经历和遇见的70%的公司会选择视而不见，必竟，中国的IT还是以Business is the king。
于是，来了一次业务量上的井喷，而此时的系统再也跟不上节奏了，最后，它带来的负面影响不堪想像。
如果説业务响应慢，它会让你的企业有所损失。
那么我们説当发生了：系统在业务迫切需要时它的crash，那才是真正要了你企业的命的。
不信？
来看！
第二章 一个真实的案例
这是笔者亲身经历的一个案例，某巨型企业面临业务快速发展，需要把原有的线下系统做成线上，因此委托了一家乙方来进行系统的开发。系统上线之初一切运行良好一切满足了乙方的功能要求，而且开发异常的快速，该企业领导人相当满意。
第二年，系统线上用户翻了近百倍，该系统开始发生有规律性的性能问题，每天的晚上20：00左右在系统做日结盘点时就会经常宕机，一开始宕机4-5次，再往后开始每隔30分钟宕机一次。
来来回回让负责开发和维护的乙方来过10几次现场，无果。整个性能问题会让日結从20：00做到零晨2点都做不完导致了那个班次的所有女员工要么辞职，要么就不做那个班次的工作了，因此那真的是要死人的节奏。
最后，我，当时的一个小屌丝，来到了现场。
当时我记得是夏天，7月的晚上大概在21：45分，到了现场看了状态后，开始查看JVM进程、日志，最终发觉他们用的还是小型机，中间件为WAS，最后通过日志、设计文档和代码证实其根本原因在于：
日结时经常业务人员会查看一些报表和产生报表数据，而这一切竟然都是用的是web session来暂存数据的，数据库倒也不大，日结时会把全schema做一个备份，即把1.2GB左右的oracle整个schema存入内存进行备份，然后同时有20多个业务人员在前端查看一些日报，日报是带翻页的，每点一次翻写，数据都会从session中取。
当时的数据量为8万条一天左右，全部放入user session然后用数组索引下标去做翻页。
笔者同时结合了另外一些点给己方的项目经理和VP提出了改进意见，可能耗时在1个半月左右，但是为了响应业务，还是设置了一个紧急方案，内容为：
- 日结时先禁用报表功能，以多线程把数据导成EXCEL并放置于share folder的形式为需要查看报表的业务人员提供报表，即一个excel多个sheet，供所有业务人员查看，但是数据会有一定的延迟，同时把该功能独立成一个新的模块
- EOD中把整个SCHEMA先LOAD进内存的方式改成外部exp命令驱动式的数据库备份
- 同时，安排3-4个人员开始重构性能有关的service层代码
但是，己方的项目经理却选择了如下的方案：
- 给小型机加了一根8GB内存，哇，08年啊，客户有钱真好骗，加完内存后，嘿嘿，原来30分钟OUT OF MEMORY一次，现在变成了42分钟OOM一次，不错，还是有效果的哦（干咳）
- 做WAS集群，2台小型机。。。吼吼。。。不错，搞了半天最后连服务都起不来了，再还原回单机状
最后，由VP和项目经理拍板，一个月2000多RMB雇了一个人，坐在机房里，只要出现OOM了就用手点一下这个机器上的重启按钮。。。。。。
再最后，就是本文引子中的一文，“杀了华陀死了曹操”，客户很简单的，不管你理由的搞不定就“杀”，禁了你所有的业务，很正常呀。
曾经四面威风大喊着以business is the king为名号的该项目PM。。。曾喊着业务你们不懂的先满足业务再来谈技术的该项目的产品经理。。。曾觉得你连业务都不懂做什么技术呢的VP。。。曾放弃了最宝贵2个月时间的该公司的老总。。。而如今却无法面对客户砍了这个项目同时禁了你的合作的一纸EMAIL。
第三章 系统的性能是真的致命的
做一个系统，不难，可能只要几个月甚至短的2个月，3个月的时间。
而让一个系统能够服务于业务运行个3-5年，嘿嘿，有多少能做到呢？
国人式的爆富催化了IT遍地开花！而如今真正可以存活的有几家?
撇开合规问题被迫倒去的那些，大部分都是倒在了无法满足几何次方増加的用户量以及扫了“长尾”后无法真正的做到“利基”，这就是一个通病。
技术为了先满足业务，肯定是要做一定的妥协的，我们不提倡“大技术”论，但是却需要在后期有步骤有计划递进和切合实际的去解决系统的性能问题。
要知道，当真的性能问题爆发时，你们的业务和母体公司会面临2种境地：
1. 客户还没完全关注到这个点上，你还有时间可以投入成本去做优化
2. 业务此时己经收不住了，而客户的抱怨开始直线上升，此时，你面临的很可能就是“曹操式的结局”
当然，更有甚者还把“华陀”全杀了，那怎么办呢？GOD KNOWS。
第四章 性能问题举例及影响范围
第五章 我们来看看一些关键行业的性能指标
随着计算机硬件的发展，这些指标其实己经算是“中等”水平了。
第六章 我们提倡在开发过程中自测性能
因为自测是避免系统性能问题的第一道屏障，系统性能自测并不像有些人想像中的高大上，1号店在12，13年时曾有一道面试题：
问你一个页面后台是SPRING MVC+MYBATIS，连着ORACLE，然后用户在该页面点查询按钮后卡死，请问你如何去分析这个问题。
不能回答的人：5分钟，甚至1分钟就説完了自己对该问题的认识
能回答的人：可以滔滔不绝，1小时，3小时，甚至和你说几周都説不完
这道题考的就是一个普通的开发人员或者我们说叫高级开发人员，是如何在日常的开发任务中自己去考虑你负责的模块和代码的性能的。
自测环节中还需要考虑场景模拟
、
开发过程中对于DB的调优步骤
由其是互联网式的企业，开发面向全栈，而生产DB的第一手参数调优是取自于开发团队的
我前面有好几篇博文大量长篇幅的阐述了一些DB的调优手段、索引、甚至底层参数和OS级调优，相关的详细手段与步骤都可以参考我之前的博文。
系统参数的调优
请考虑下面几个环节
开发自用压力测试和监控工具的选择
其中 ibm heap dump是经常用的，由其对于一些跨省、跨国的远程生产环境调试，服务器轻易是不会给你进入生产或者是宕机查看问题的，因此在很多时候我们依赖于jvm的heap dump和jmap, jstack这些小工具、小命令行来分析JVM里到底干了些什么事。
由于本章不是讲这种小工具怎么用的而是关注于一个全局的方法论的问题，因此至于这些小工具怎么使用，请自行GOOGLE一下即可，到处都有讲解。关键在于你是不是经常去用。
现在知道为什么有些好点的互联网企业面试时会问你什么JAVA的类的结构、HASHMAP的原码、什么JVM核心机制这些问题了的真正原因了吧？
下面介绍几个植入式的可视化的适合于开发的性能开发与监视工具
Glowroot
这款工具很好玩，它可以把它的jar包伴随着你的容器一起启动起来，你只要在启动命令行里多加一个参数。
它是一个开源的小工具，唯一不好的地方在于它对于多节点不支持集群，但是通过它可以看到单个JVM内的任何状况且可以通过某个方法一直跟踪到你里面执行的具体的一个SQL。
jmeter
这个就不用多介绍了吧。提示：使用BADBOY抓网页点击动作然后export成jmeter的计划文件。
IBM Heap Analyzer
一般java应用在发生OOM时会产生一个dump文件
启动示例：
/usr/java6/bin/java – Xmx4000m – jar ha36.jar heapdump.20120602.134015.430370.phd
DRUID后台监控报表
阿里的开源Datasource Connection Pool组件，它的好处就在于可以伴随着JVM启动起一个SQL监控后台，远程可以通过这个控台查看到TOP30,40,50效率最差的是哪些SQL以及它们是怎么写的。
我们一般的优化就是扫这个DRUID后台，把所有高于1秒的（控台中会标红那些个超过1秒以上的SQL）全部优化到1秒之内。
大家想，一个SQL从100秒优化到了1秒，有人觉得不得了了，可是我告诉你，在许多互联网企业内生产上的SQL执行时间1S都算慢的，为什么？假设我有1万个并发（互联网企业动不动就是上万的），你觉得这个功能或者是点击得要花多久？
因此我们一般力争把所有的SQL调优到0.5秒内，有时看看能否达到0.1秒甚至为0.0X秒，这就是一个程序员为什么会对着一个SQL调优花上2天，3天的原因了，这是真正的技术而不再是一个码农了。
极致优化你的SQL
系统性能调优的5步方法论
从下到上、反复式、犁地式的调优，直到最优结果
系统调优时需要观察的一些关键指标
这些具体指标干什么的，在我的博客开头3天博文中都已经详细讲述过了。
看几个极端调优实例报告吧
从12.483秒到0.414提高了多少倍？2000%以上的效率吧，是吧？
再来看一个
灰的和白的是调优前和调优后，对比一下看看31.92秒到5.935秒的单功能调优提高了多少？
集群有时不一定好过单机
不要动不动就是集群，要知道集群后，网络间的来回心跳同步、磁盘的开销是高于单机的，包括运维与监控的复杂度与成本，请考虑一下ROI的问题。
因此，在你没有极端单机调优到最优的情况下，先请不要把集群作为你的首选优化方案。
推荐相关书籍与博文
借此，我推荐几本相关的书籍和重登一下之前和性能相关的几篇主要的博文供大家参考
总结
这篇文章前面是写给PM、产品经理、业务主管甚至是CTO、CIO、COO看的，曹操谁都想做，天下英雄，唯使君与操耳？ 但是曹操的天下，嘿嘿只安逸了100年不到，而真正盛世则是338年后的贞观之治。
为什么有贞观之治？唐太宗极积采纳谏言，把魏征当成自己的一面镜子进行天天的反省。
所谓忠言逆耳，苦口良药。
性能无小事，有事则必是大事。
开始不注意性能，你可以得到“速度”，到了后期，嘿嘿，性能一出问题，那是要你的老命了亲爱的BUSINESS IS THE KING的同协们？
什么叫BUSINESS IS THE KING？IT搞毛BUSINESS啊？让IT去读上岗证、会计证、保险证？
IT里的所谓业务即，用IT的语言、思路可以把一切传统行业的业务、操作、使用去用逻辑和技术实现讲清楚，甚至达到线上替代线下这么一个效果，即我们所説的solution、解决方案，这是真正的业务。
产品经理出身必须为技术-见马化腾的一篇著作中有详细阐述，正是因为IT里的业务其实就是一个“产品功能交互的闭环”，是一个落地的方案，就算换了一个团队的开发，你也可以靠2个嘴皮子嗒巴嗒巴把所有的业务逻辑讲出来然后让兄弟们敲代码实现即可，再説白了点，所谓的业务就是挣钱的点子。
话再回过来説，这篇文章的下半段还是写给我们的技术人员看的，就是説：就算碰上了曹操，我们还是要坚持做华陀，因为就算有100个人里有1个可以听进的，唉呀。。。那也是做了一件善举。
勿要搞技术独大、技术打压
勿要搞业务独大、业务为王
要相辅相成，融汇贯通，21世纪单赢就是输，双赢才是真正的赢-摘自习大大名言。
因此，这也是我的博客的宗旨，吾以吾血荐我中华之IT。