原文出处：
在 Zen And The Art Of Scaling - A Koan And Epigram Approach 一文中 , Russell Sullivan 提出一个很有趣的设想：一共有20种经典的瓶颈。这听起来就像只有20种基本的故事情节（20 basic story plots）那样让人怀疑。不过基于每个人不同的分类方式，这个说法或许是对的，但是在现实中，众所周知，瓶颈是无穷无尽的而且涉及方方面面。
一天， 来自 Terracotta 的 Aurelien Broszniowski 给我电邮了一份他心中的瓶颈列表，我们同时把我们的邮件抄送给了Russell, 他也给出了他的列表。而我也有我自己的想法。 所以，下面就是这几碗水煮成的一锅石头汤（ http://en.wikipedia.org/wiki/Stone_soup， stone soup典故） Russell 说要是年轻的时候就知道这些该多好啊，而对我来说则可以提供更多的思路。你的经验越多，处理过不同类型的项目，你就可以给这个列表增加更多的内容。因此当你在阅读这个列表时，或者是在整理自己的列表时，多年的丰富经验的积累以及遇到的一些小挫折，每一个故事都值得进行总结。 数据库:工作中数据大小超过可用内存 RAM长短查询混合写-写 冲突大的联合查询占光内存虚拟化:共享 HDD 存储，磁盘寻道挂起云平台中的网络 I/O 波动 编程:线程：死锁、相对于事件驱动来说过于重量级、调试、线程数与性能比非线性事件驱动编程：回调的复杂性、函数调用中如何保存状态（how-to-store-state-in-function-calls）缺少profile工具、缺少trace工具、缺少日志工具单点故障、横向不可扩展有状态的应用搓设计：一台机器上能跑，几个用户也能跑，几个月后，几年后，尼玛，发现扛不住了，整个架构需要重写。算法复杂度依赖于诸如DNS查找等比较搞人的外部组件栈空间 磁盘：本地磁盘存取随机磁盘读写 -> 磁盘寻道磁盘碎片化写入超过SSD容量的数据导致SSD硬盘性能降低操作系统：内核缓冲刷入磁盘，填充linux缓冲区缓存TCP缓冲区过小文件描述符限制功率分配缓存:
不使用memcachedHTTP中，header，etags，不压缩（headers, etags, not gzipping）没有充分使用浏览器缓存功能字节码缓存（如PHP）L1/L2缓存. 这是个很大的瓶颈. 把频繁使用的数据保持在L1/L2中. 设计到的方面很多：网络数据压缩后再发送，基于列压缩的DB中不解压直接计算等等。有TLB友好的算法。最重要的是牢固掌握以下基础知识：多核CPU、L1/L2，共享L3，NUMA内存，CPU、内存之间的数据传输带宽延迟，磁盘页缓存，脏页，TCP从CPU到DRAM到网卡的流程。 CPU:CPU 过载上下文切换 -> 一个内核上跑了太多的线程，linux调度对于应用来说很不友好, 太多的系统调用, 等等...IO 等待 -> 所有的CPU都挂起等待比较慢的IOCPU 缓存: 缓存数据是一个为了平衡不同实例有不同的值和繁重的同步缓存数据保持一致，而精心设计的一个进程。背板吞吐量 网络:网卡的最大输出带宽，IRQ达到饱和状态，软件中断占用了100%的CPUDNS查找丢包网络路由瞎指挥网络磁盘访问共享SAN（Storage Area Network)服务器失败 -> 服务器无响应过程:
测试时间 Testing time开发时间 Development time团队人数 Team size预算 Budget代码缺陷 Code debt 内存:内存溢出 -> 杀进程，进入 swap ，越来越慢内存溢出导致磁盘频繁读写（swap相关）内存库开销内存碎片Java 需要垃圾收集导致程序暂停C 语言的 malloc 无法分配 如果你有更多的瓶颈要添加或者建议修复，请加入。感谢 Aurelien 和 Russel。