1. 在 Java™ 和 PHP 这类语言中，每个连接都会生成一个新线程，每个新线程可能需要 2 MB 的配套内存。在一个拥有 8 GB RAM 的系统上，理论上最大的并发连接数量是 4,000 个用户。随着您的客户群的增长，如果希望您的 Web 应用程序支持更多用户，那么，您必须添加更多服务器。当然，这会增加服务器成本、流量成本和人工成本等成本。除这些成本上升外，还有一个潜在技术问题，即用户可能针对每个请求使用不同的服务器，因此，任何共享资源都必须在所有服务器之间共享。鉴于上述所有原因，整个 Web 应用程序架构（包括流量、处理器速度和内存速度）中的瓶颈是：服务器能够处理的并发连接的最大数量。
（http://www.ibm.com/developerworks/cn/opensource/os-nodejs/index.html?ca=drs）
PS:
Node 公开宣称的目标是 “旨在提供一种简单的构建可伸缩网络程序的方法”，Node 解决这个问题的方法是：更改连接到服务器的方式。每个连接发射一个在 Node 引擎的进程中运行的事件，而不是为每个连接生成一个新的 OS 线程（并为其分配一些配套内存）。Node 声称它绝不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。Node 还宣称，运行它的服务器能支持数万个并发连接。
现在您有了一个能处理数万个并发连接的程序，那么您能通过 Node 实际构建什么呢？如果您有一个 Web 应用程序需要处理这么多连接，那将是一件很 “恐怖” 的事！那是一种 “如果您有这个问题，那么它根本不是问题” 的问题。在回答上面的问题之前，我们先看看 Node 的工作原理以及它的设计运行方式。
--------------------------------------------------------------------------------
2. 在不改动代码与SQL语句的前提下，如何去改善和提高web server与app server的性能，千万不要小觑这一内容，它可以让你在不改动代码的情况下得到10-20倍以上的性能提高，网上有其它的大牛们写过一篇文章叫“Tomcat如何支持到1000个用户”，经过几个重大工程的实践，Opensource的Tomcat如果调优的好不只可以支持者1000个用户，尤其当你的布署环境是64位操作系统的情况下，可能能够支持更大更高的并发性能，(http://blog.csdn.net/lifetragedy/article/details/7707455)
--------------------------------------------------------------------------------
3.
典型PC系统各种操作指令的大概时间
|
fetch from L1 cache memory 从一级缓存中读取数据 |
0.5 nanosec |
|
execute typical instruction 执行基本指令 |
1 nanosec |
|
branch misprediction 分支误预测 |
5 nanosec |
|
fetch from L2 cache memory 从二级缓存获取数据 |
7 nanosec |
|
Mutex lock/unlock 互斥加锁/解锁 |
25 nanosec |
|
fetch from main memory 从主内存获取数据 |
100 nanosec |
|
send 2K bytes over 1Gbps network 通过1G bps 的网络发送2K字节 |
20us (20, 000 nanosec) |
|
read 1MB sequentially from memory 从内存中顺序读取1MB数据 |
250us (250, 000 nanosec) |
|
fetch from new disk location (seek) 从新的磁盘位置获取数据（随机读取） |
8ms (8, 000, 000 nanosec) |
|
read 1MB sequentially from disk 从磁盘中顺序读取1MB数据 |
20ms (20, 000, 000 nanosec) |
|
send packet US to Europe and back 从美国发送一个报文包到欧洲再返回 |
150ms (150, 000, 000 nanosec) |
--------------------------------------------------------------------------------
4.
谷歌数据：网页加载超过4秒，25%人会放弃；手机网页超过10秒，50%用户会放弃，60%人不再返回；Google搜索结果慢0.4秒，一天搜索量减少800万次；40%移动购物者会放弃加载时间超过3秒的网站；亚马逊每天销售额约6700万美元，网页延迟1秒可导致全年损失16亿美元。
--------------------------------------------------------------------------------
5.1 数据库
工作任务内存超过可用的RAM内存
长/短查询
写入冲突
大连接（join）占用内存
5.2 虚拟化
共享一个HDD、磁盘寻死（disk seek death）
在云端网络I/O波动
5.3 编程
线程：死锁、调试、非线性扩展等
事件驱动编程：callback()过于复杂、如何在函数调用中存储有状态等
缺乏调优、跟踪、日志等
单模块不可扩展、单点故障(SPOF:Single Point Of Failure)、非横向扩展等
有状态应用程序
设计问题：开发的应用程序只在自己的机器行运行正常，或者只是在几个人测试的时候正常（没有经历压力测试）。
算法过于复杂
相关服务，例如DNS查找以及其他可能屏蔽的服务
堆栈空间
5.4 磁盘
访问本地磁盘
随机访问磁盘I/O
磁盘碎片
当SSD写入的数据大于SSD容量时，性能会下降
5.5 OS
Fsync饱和，Linux缓冲区填塞（Fsync flushing, linux buffer cache filling up）
TCP缓冲区太小
文件描述符限制
功率分配（Power budget）
5.6 缓存
没使用memcached（数据库崩溃）
HTTP中：headers、etags、没有使用gzip压缩等。
没有充分利用浏览器缓存
字节码缓存（如PHP）
L1/L2缓存：这是个令人头疼的大瓶颈。把关键并且经常访问的数据存储在L1/L2中。这涉及到很多：snappy网络I/O,列数据库直接在压缩数据上运行算法等。利用一些技术不销毁你的TLB。最重要的思想是紧紧的抓住计算机的体系结构，涉及多核CPU，L1/L2，共享的L3，NUMA RAM，从DRAM到芯片数据传输带宽/延迟，DRAM缓存的DiskPages，DirtyPages，流经CPU<->DRAM<->NIC的TCP包。
5.7 CPU
CPU过载
内容切换—>单核上开启的线程过多、Linux调度器、系统调用太多等
IO等待—>所有的CPU在同速等待
CPU缓存：缓存数据是一个细粒度进程，为了在多个实例与不同的值数据之间找到正确的平衡，来保持缓存数据的一致性和繁重同步。
底板吞吐量（Backplane throughput）
5.8 网络
NIC刷爆、IRQ饱和、软中断占用掉了100%CPU
DNS查询
数据包丢失
网络中存在预期外的路由
访问网络磁盘
共享SAN
服务器故障—>无法从服务处得到响应
5.9 进程
测试时间
开发时间
团队规模
预算
代码债务
5.10 内存
内存不足—>杀死进程，切换到swap，挂起
内存不足导致磁盘交换（与swap相关）
记忆库开销过大（Memory library overhead）
内存分片（在Java中需要会因为内存回收而停顿；在C中，malloc总是开始分配内存）
--------------------------------------------------------------------------------