首页 > 代码库 > 从曹操杀华陀而联想到的系统性能问题才是真正的致命的问题
从曹操杀华陀而联想到的系统性能问题才是真正的致命的问题
引子
公元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台小型机。。。吼吼。。。不错，搞了半天最后连服务都起不来了，再还原回单机状
第三章 系统的性能是真的致命的
第四章 性能问题举例及影响范围
第五章 我们来看看一些关键行业的性能指标
第六章 我们提倡在开发过程中自测性能
自测环节中还需要考虑场景模拟
、开发过程中对于DB的调优步骤
系统参数的调优
开发自用压力测试和监控工具的选择
Glowroot
jmeter
IBM Heap Analyzer
/usr/java6/bin/java – Xmx4000m – jar ha36.jar heapdump.20120602.134015.430370.phd
DRUID后台监控报表
极致优化你的SQL
系统性能调优的5步方法论
从下到上、反复式、犁地式的调优，直到最优结果
系统调优时需要观察的一些关键指标
这些具体指标干什么的，在我的博客开头3天博文中都已经详细讲述过了。
看几个极端调优实例报告吧
从12.483秒到0.414提高了多少倍？2000%以上的效率吧，是吧？
再来看一个
灰的和白的是调优前和调优后，对比一下看看31.92秒到5.935秒的单功能调优提高了多少？
集群有时不一定好过单机
不要动不动就是集群，要知道集群后，网络间的来回心跳同步、磁盘的开销是高于单机的，包括运维与监控的复杂度与成本，请考虑一下ROI的问题。
因此，在你没有极端单机调优到最优的情况下，先请不要把集群作为你的首选优化方案。
推荐相关书籍与博文
借此，我推荐几本相关的书籍和重登一下之前和性能相关的几篇主要的博文供大家参考
PLSQL优化
PLSQL执行计划解说
MYSQL系列教程
通向架构师的道路开篇几篇重要的关于性能方面的博文
Oracle基础知识
总结
这篇文章前面是写给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。
从曹操杀华陀而联想到的系统性能问题才是真正的致命的问题