提高服务器的并发能力与站点的技术优化
2011-01-25 11:08:27 
阿炯
提高服务器的并发处理能力
什么是服务器并发处理能力：一台服务器在单位时间里能处理的请求越多，服务器的能力越高，也就是服务器并发处理能力越强，有什么方法衡量服务器并发处理能力呢？
1. 吞吐率
吞吐率，单位时间里服务器处理的最大请求数，单位req/s。
从服务器角度，实际并发用户数的可以理解为服务器当前维护的代表不同用户的文件描述符总数，也就是并发连接数。服务器一般会限制同时服务的最多用户数，比如apache的MaxClents参数。
这里再深入一下，对于服务器来说，服务器希望支持高吞吐率，对于用户来说，用户只希望等待最少的时间，显然双方不能满足，所以双方利益的平衡点，就是我们希望的最大并发用户数。
2. 压力测试
有一个原理一定要先搞清楚，假如100个用户同时向服务器分别进行10个请求，与1个用户向服务器连续进行1000次请求，对服务器的压力是一样吗？
实际上是不一样的，因对每一个用户，连续发送请求实际上是指发送一个请求并接收到响应数据后再发送下一个请求。这样对于1个用户向服务器连续进行1000次请求，任何时刻服务器的网卡接收缓冲区中只有1个请求，而对于100个用户同时向服务器分别进行10个请求，服务器的网卡接收缓冲区最多有100个等待处理的请求，显然这时的服务器压力更大。
压力测试前提考虑的条件
并发用户数: 指在某一时刻同时向服务器发送请求的用户总数(HttpWatch)
总请求数
请求资源描述
请求等待时间(用户等待时间)
用户平均请求的等待时间
服务器平均请求处理的时间
硬件环境
压力测试中关心的时间又细分以下2种:
用户平均请求等待时间（这里暂不把数据在网络的传输时间，还有用户PC本地的计算时间计算入内）
服务器平均请求处理时间
用户平均请求等待时间主要用于衡量服务器在一定并发用户数下，单个用户的服务质量；而服务器平均请求处理时间就是吞吐率的倒数。一般来说，用户平均请求等待时间 = 服务器平均请求处理时间 * 并发用户数
怎么提高服务器的并发处理能力
1. 提高CPU并发计算能力
服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计使得多个任务可以轮流使用系统资源。
这些资源包括CPU，内存以及I/O. 这里的I/O主要指磁盘I/O, 和网络I/O。
多进程 & 多线程
多执行流的一般便是进程，多进程的好处可以对CPU时间的轮流使用，对CPU计算和IO操作重叠利用。这里的IO主要是指磁盘IO和网络IO，相对CPU而言，它们慢的可怜。而实际上，大多数进程的时间主要消耗在I/O操作上。
现代计算机的DMA技术可以让CPU不参与I/O操作的全过程，比如进程通过系统调用，使得CPU向网卡或者磁盘等I/O设备发出指令，然后进程被挂起，释放出CPU资源，等待I/O设备完成工作后通过中断来通知进程重新就绪。
对于单任务而言，CPU大部分时间空闲，这时候多进程的作用尤为重要。多进程不仅能够提高CPU的并发度。其优越性还体现在独立的内存地址空间和生命周期所带来的稳定性和健壮性，其中一个进程崩溃不会影响到另一个进程。但是进程也有如下缺点：
fork()系统调用开销很大：prefork
进程间调度和上下文切换成本：减少进程数量
庞大的内存重复：共享内存
IPC编程相对比较麻烦
减少进程切换
当硬件上下文频繁装入和移出时，所消耗的时间是非常可观的。可用Nmon或sysstate工具监视服务器每秒的上下文切换次数。为了尽量减少上下文切换次数，最简单的做法就是减少进程数，尽量使用线程并配合其它I/O模型来设计并发策略。
还可以考虑使用进程绑定CPU技术，增加CPU缓存的命中率。若进程不断在各CPU上切换，这样旧的CPU缓存就会失效。
减少使用不必要的锁
服务器处理大量并发请求时，多个请求处理任务时存在一些资源抢占竞争，这时一般采用“锁”机制来控制资源的占用。当一个任务占用资源时，我们锁住资源，这时其它任务都在等待锁的释放，这个现象称为锁竞争。
通过锁竞争的本质，我们要意识到尽量减少并发请求对于共享资源的竞争。比如在允许情况下关闭服务器访问日志，这可以大大减少在锁等待时的延迟时间。要最大程度减少无辜的等待时间。
这里说下无锁编程，就是由内核完成这个锁机制，主要是使用原子操作替代锁来实现对共享资源的访问保护。使用原子操作时，在进行实际的写操作时，使用了lock指令，这样就可以阻止其他任务写这块内存，避免出现数据竞争现象。原子操作速度比锁快，一般要快一倍以上。
例如fwrite(), fopen()，其是使用append方式写文件，其原理就是使用了无锁编程，无锁编程的复杂度高，但是效率快，而且发生死锁概率低。
考虑进程优先级
进程调度器会动态调整运行队列中进程的优先级，通过top观察进程的PR值。
考虑系统负载
可在任何时刻查看/proc/loadavg, top中的load average也可看出。
考虑CPU使用率
除了用户空间和内核空间的CPU使用率以外，还要关注I/O wait,它是指CPU空闲并且等待I/O操作完成的时间比例(top中查看wa的值)。
2. 考虑减少内存分配和释放
服务器的工作过程中，需要大量的内存，使得内存的分配和释放工作尤为重要。可以通过改善数据结构和算法复制度来适当减少中间临时变量的内存分配及数据复制时间，而服务器本身也使用了各自的策略来提高效率。
例如Apache在运行开始时一次申请大片的内存作为内存池，若随后需要时就在内存池中直接获取，不需要再次分配，避免了频繁的内存分配和释放引起的内存整理时间。再如Nginx使用事件来处理请求，使得多个'worker'之间可以共享内存资源，从而令它的内存总体使用量大大减少。Nginx分阶段的内存分配策略，按需分配，及时释放，使得内存使用量保持在很小的数量范围。
另外，还可以考虑共享内存。
共享内存指在多处理器的计算机系统中，可以被不同中央处理器（CPU）访问的大容量内存，也可以由不同进程共享，是非常快的进程通信方式。但是使用共享内存也有不好的地方，就是对于多机器时数据不好统一。
shell命令ipcs可用来显示系统下共享内存的状态，函数shmget可以创建或打开一块共享内存区，函数shmat将一个存在的共享内存段连接到本进程空间，函数shmctl可以对共享内存段进行多种操作，函数shmdt函数分离该共享内存。
3. 考虑使用持久连接
持久连接也为长连接，它本身是TCP通信的一种普通方式，即在一次TCP连接中持续发送多分数据而不断开连接。与它相反的方式称为短连接，也就是建立连接后发送一份数据就断开，然后再次建立连接发送下一份数据， 周而复始。
是否采用持久连接，完全取决于应用特点。
从性能角度看，建立TCP连接的操作本身是一项不小的开销，在允许的情况下，连接次数越少，越有利于性能的提升；尤其对于密集型的图片或网页等小数据请求处理有明显的加速所用。HTTP长连接需要浏览器和web服务器的共同协作，目前浏览器普遍支持长连接，表现在其发出的HTTP请求数据头中包含关于长连接的声明，如下：Connection: Keep-Alive
主流的web服务器都支持长连接，比如apache中，可以用KeepAlive off关闭长连接。对于长连接的有效使用，还有关键一点在于长连接超时时间的设置，即长连接在什么时候关闭吗？
Apache的默认设置为5s, 若这个时间设置过长，则可能导致资源无效占有，维持大量空闲进程，影响服务器性能。
4. 改进I/O 模型
I/O操作根据设备的不同分为很多类型，比如内存I/O, 网络I/O, 磁盘I/O。
对于网络I/O和磁盘I/O，它们的速度要慢很多，尽管使用RAID磁盘阵列可通过并行磁盘磁盘来加快磁盘I/O速度，购买独享网络带宽以及使用高带宽网络适配器可以提高网络I/O的速度。
但这些I/O操作需要内核系统调用来完成，这些需要CPU来调度，这使得CPU不得不浪费宝贵的时间来等待慢速I/O操作。
我们希望让CPU足够少的时间在i/O操作的调度上，如何让高速的CPU和慢速的I/O设备更好地协调工作，是现代计算机一直探讨的话题。各种I/O模型的本质区别在于CPU的参与方式。
DMA技术
I/O设备和内存之间的数据传输方式由DMA控制器完成。在DMA模式下，CPU只需向DMA下达命令，让DMA控制器来处理数据的传送，这样可以大大节省系统资源。
异步I/O
异步I/O指主动请求数据后便可以继续处理其它任务，随后等待I/O操作的通知，这样进程在数据读写时不发生阻塞。异步I/O是非阻塞的，当函数返回时，真正的I/O传输已经完成，这让CPU处理和I/O操作达到很好的重叠。
I/O多路复用
epoll服务器同时处理大量的文件描述符是必不可少的，若采用同步非阻塞I/O模型，若同时接收TCP连接的数据，就必须轮流对每个socket调用接收数据的方法，不管这些socket有没有可接收的数据，都要询问一次。
假如大部分socket并没有数据可以接收，那么进程便会浪费很多CPU时间用于检查这些socket有没有可以接收的数据。多路I/O就绪通知的出现，提供了对大量文件描述符就绪检查的高性能方案，它允许进程通过一种方法同时监视所有文件描述符，并可以快速获得所有就绪的文件描述符，然后只针对这些文件描述符进行数据访问。
epoll可以同时支持水平触发和边缘触发，理论上边缘触发性能更高，但是代码实现复杂，因为任何意外的丢失事件都会造成请求处理错误。epoll主要有2大改进：
epoll只告知就绪的文件描述符，而且当调用epoll_wait()获得文件描述符时，返回并不是实际的描述符，而是一个代表就绪描述符数量的值，然后只需去epoll指定的一个数组中依次取得相应数量的文件描述符即可。
这里使用了内存映射(mmap)技术，这样彻底省掉了这些文件描述符在系统调用时复制的开销。
epoll采用基于事件的就绪通知方式。其事先通过epoll_ctrl()注册每一个文件描述符，一旦某个文件描述符就绪时，内核会采用类似callback的回调机制，当进程调用epoll_wait()时得到通知。
Sendfile
大多数时候，我们都向服务器请求静态文件，比如图片，样式表等。在处理这些请求时，磁盘文件的数据先经过内核缓冲区，然后到用户内存空间，不需经过任何处理，其又被送到网卡对应的内核缓冲区，接着再被送入网卡进行发送。
Linux提供sendfile()系统调用，可以讲磁盘文件的特定部分直接传送到代表客户端的socket描述符，加快了静态文件的请求速度，同时减少CPU和内存的开销。
适用场景：对于请求较小的静态文件，sendfile发挥的作用不那么明显，因发送数据的环节在整个过程中所占时间的比例相比于大文件请求时小很多。
内存映射
Linux内核提供一种访问磁盘文件的特殊方式，它可以将内存中某块地址空间和我们指定的磁盘文件相关联，从而对这块内存的访问转换为对磁盘文件的访问。这种技术称为内存映射。
多数情况下，内存映射可以提高磁盘I/O的性能，无须使用read()或write()等系统调用来访问文件，而是通过mmap()系统调用来建立内存和磁盘文件的关联，然后像访问内存一样自由访问文件。
缺点：在处理较大文件时，内存映射会导致较大的内存开销，得不偿失。
直接I/O
在linux 2.6中，内存映射和直接访问文件没有本质差异，因为数据需要经过2次复制，即在磁盘与内核缓冲区之间以及在内核缓冲区与用户态内存空间。引入内核缓冲区的目的在于提高磁盘文件的访问性能，然而对于一些复杂的应用，比如数据库服务器，它们为了进一步提高性能，希望绕过内核缓冲区，由自己在用户态空间实现并管理I/O缓冲区，比如数据库可根据更加合理的策略来提高查询缓存命中率。
另一方面，绕过内核缓冲区也可以减少系统内存的开销，因内核缓冲区本身就在使用系统内存。
Linux在open()系统调用中增加参数选项O_DIRECT,即可绕过内核缓冲区直接访问文件,实现直接I/O。
在Mysql中，对于Innodb存储引擎，自身进行数据和索引的缓存管理，可在my.cnf配置中分配raw分区跳过内核缓冲区，实现直接I/O。
5. 改进服务器并发策略
服务器并发策略的目的，是让I/O操作和CPU计算尽量重叠进行，一方面让CPU在I/O等待时不要空闲，另一方面让CPU在I/O调度上尽量花最少的时间。
一个进程处理一个连接，非阻塞I/O
这样会存在多个并发请求同时到达时，服务器必然要准备多个进程来处理请求。其进程的开销限制了它的并发连接数。但从稳定性和兼容性的角度，则其相对安全，任何一个子进程的崩溃不会影响服务器本身，父进程可以创建新的子进程；这种策略典型的例子就是Apache的fork和prefork模式。对于并发数不高（如150以内）的站点同时依赖Apache其它功能时的应用选择Apache还是可以的。
一个线程处理一个连接，非阻塞IO
这种方式允许在一个进程中通过多个线程来处理多个连接，一个线程处理一个连接。Apache的worker模式就是这种典型例子，使其可支持更多的并发连接。不过这种模式的总体性能还不如prefork，所以一般不选用worker模式。
一个进程处理多个连接，异步I/O
一个线程同时处理多个连接，潜在的前提条件就是使用IO多路复用就绪通知。这种情况下，将处理多个连接的进程叫做worker进程或服务进程。worker的数量可以配置，如Nginx中的worker_processes 4。
一个线程处理多个连接，异步IO
即使有高性能的IO多路复用就绪通知，但磁盘IO的等待还是无法避免的。更加高效的方法是对磁盘文件使用异步IO，目前很少有Web服务器真正意义上支持这种异步IO。
6. 改进硬件环境
还有一点要提及的是硬件环境，服务器的硬件配置对应用程序的性能提升往往是最直接，也是最简单的方式，这就是所谓的scale up。
多进、线程程序在CPU上是如何工作的
此文中的大部分资料来自于网络上，只是觉得把有道理的整理一下，方便以后查阅。
线程与进程
进程：可以理解成一个程序，是占有一定Cpu资源、它是系统进行资源分配和调度的一个独立单位，重点在系统调度和单独的单位，也就是说进程是可以独立运行的一段程序。比如说，运行火狐浏览器就是一个进程。
线程：一个进程至少有一个线程。线程是CPU的实际调度和分派的基本单位，他是比进程更小的能独立运行的基本单位，线程自己基本上不拥有系统资源。比如说浏览器，它就有很多的线程，每一个标签就是一个新的线程，这些线程共享占用着进程所占有的系统资源。
超线程：假如说我有个单核的CPU，我要是想要运行一个多线程的程序，通常情况下，只能是由Cpu在线程之间来回调度，但是当我开启了超线程，我可以在一个线程执行整数指令集的时候，而恰好在这个时候，另一个线程执行浮点指令集，而这两个指令集分数与整数指令单元和浮点指令单元来执行。那么我就可以同时执行这两个线程，这就叫超线程。而且实际上，是有大量资源被闲置着的。超线程技术允许两个线程同时不冲突地使用CPU中的资源。指令单元闲置，可以通过超线程的技术来达到提高利用率。这叫做硬件多线程技术。
CPU 工作的分配一般是以线程为级别的，只不过大部分程序一个进程只用一个线程，所以看起来好像 CPU 只能是以进程位粒度分配任务。进程是组织资源的最小单位，而线程是安排 CPU 执行的最小单位，一个逻辑 CPU 核心在某一时刻只能 hold 住一个线程。多线程当然可以利用多核，调度单元是线程，不是进程。
并发(concurrent)与并行(parallel)的区别，最早 UNIX 的调度是以 “进程” 为最小调度单位，那个时候还没有线程的概念。线程有两种，一种是 “用户态线程” ，对内核不可见，内核不可以调度，现在一般叫做线程或协程。另一种是 “内核态线程”，由内核调度，也称作轻量进程 LWP 。现在说的线程，一般不特殊指定，都是内核线程。多进程由于要 fork 两份一模一样的数据，并且要 CPU 要切换进程，也会耗费不少资源。
能不能利用多核的关键是能不能被内核调度，既然内核态线程可以被调度，自然可以利用多核。另外只要资源足够（内存） CPU 可以 hold 住任意多的进程或线程，这与 CPU 的核数无关。
CPU核数跟多线程的关系
要说多线程就离不开进程，进程和线程的区别在这里就不详细说了，只将关键的几点：
a)进程之间是相互独立的，不共享内存和数据，线程之间的内存和数据是公用的，每个线程只有自己的一组CPU指令、寄存器和堆栈，对于线程来说只有CPU里的东西是自己独享的，程序中的其他东西都是跟同一个进程里的其他线程共享的。
b)操作系统创建进程时要分配好多外部资源，所以开销大（这个跟操作系统有关，有人做过实验，Windows创建进程的开销大，Linux创建进程的开销就很小。）
再来说一下CPU，过去单CPU时代，最先是单任务阶段在一个时间点只能执行单一程序。之后发展到多任务阶段，计算机能在同一时间点并行执行多任务或多进程。虽然并不是真正意义上的“同一时间点”，而是多个任务或进程共享一个CPU，并交由操作系统来完成多任务间对CPU的运行切换，以使得每个任务都有机会获得一定的时间片运行。而现在多核CPU的情况下，同一时间点可以执行多个任务(并行)，具体到这个任务在CPU哪个核上运行，这个就跟操作系统和CPU本身的设计相关了。
假设一个极端的情况：在一台单核计算机上只运行2个程序，一个是我们的程序A，另一个是操作系统的程序B，每个程序是一个进程。单核CPU的时候，A和B在CPU上交替运行，具体的分配方式由操作系统来判断，这里猜测应该跟A和B的线程数有关，因为线程是CPU级别的，如果A有5个线程，B也有5个线程，那么CPU分配给A和B的时间应该是1：1的；如果A增加到15个线程，CPU分配给A和B的时间应该是3：1的比例。所以此时如果A的线程数多，那么获得的CPU执行次数就多，处理的速度也就快了。以上假设的前提是：①A和B的优先级相同，②A和B都是只消耗CPU资源的程序。
如果相同的情况用一个双核的计算机来处理又会是什么结果呢？假设这个双核的计算机和操作系统比较傻，把A进程分配到核1上，B进程分配到核2上，那不管A有几个线程，都是用核1来处理，那么时间肯定是一样的。不过现实中应该不会有这么傻的CPU和操作系统吧。所以赶紧还是会根据线程来进行处理，当A的线程比B多时，会占用核2来处理A的线程。
刚才说的是只消耗CPU资源的程序，但这样的程序在实际应用中基本上是没有的，总会有跟资源打交道的。比如读个文件，查个数据库，访问一个网络连接等等。这个时候多线程才真正体现出优势，在一个进程中，线程a去读文件，线程b去查数据库，线程c去访问网络，a先用一下CPU，然后去读文件，此时CPU空闲，b就用一下，然后去查数据库，……，相对于读文件、查数据库、访问网络来说CPU计算的时间几乎可以忽略不计，所以多线程实际上是计算机多种资源的并行运用，跟CPU有几个核心是没什么关系的。
CPU组件
1.在单核计算机里，有一个资源是无法被多个程序并行使用的：CPU。
没有操作系统的情况下，一个程序一直独占着全都CPU。如果要有两个任务来共享同一个CPU，程序员就需要仔细地为程序安排好运行计划–某时刻cpu和由程序A来独享，下一时刻cpu由程序B来独享，而这种安排计划后来成为OS的核心组件，被单独名命为“scheduler”，即“调度器”，它关心的只是怎样把单个CPU的运行拆分成一段一段的“运行片”，轮流分给不同的程序去使用，而在宏观上，因为分配切换的速度极快，就制造出多程序并行在一个CPU上的假象。
2.在单核计算机里，有一个资源可以被多个程序共用，然而会引出麻烦：内存。
在一个只有调度器，没有内存管理组件的操作系统上，程序员需要手工为每个程序安排运行的空间 — 程序A使用物理地址0x00-0xff,程序B使用物理地址0x100-0x1ff，等等。然而这样做有个很大的问题：每个程序都要协调商量好怎样使用同一个内存上的不同空间，软件系统和硬件系统千差万别，使这种定制的方案没有可行性。为了解决这个麻烦，计算机系统引入了“虚拟地址”的概念，从三方面入手来做：
2.1、硬件上，CPU增加了一个专门的模块叫MMU，负责转换虚拟地址和物理地址。
2.2、操作系统上，操作系统增加了另一个核心组件：memory management，即内存管理模块，它管理物理内存、虚拟内存相关的一系列事务。
2.3、应用程序上，发明了一个叫做“进程”的模型，（注意）每个进程都用“完全一样的”虚拟地址空间，然而经由操作系统和硬件MMU协作，映射到不同的物理地址空间上。不同的“进程”，都有各自独立的物理内存空间，不用一些特殊手段，是无法访问别的进程的物理内存的。
3.现在，不同的应用程序，可以不关心底层的物理内存分配，也不关心CPU的协调共享了。然而还有一个问题存在：有一些程序，想要共享CPU，并且还要共享同样的物理内存，这时候，一个叫“线程”的模型就出现了，它们被包裹在进程里面，在调度器的管理下共享CPU，拥有同样的虚拟地址空间，同时也共享同一个物理地址空间，然而，它们无法越过包裹自己的进程，去访问别一个进程的物理地址空间。
4.进程之间怎样共享同一个物理地址空间呢？不同的系统方法各异，符合posix规范的操作系统都提供了一个接口，叫mmap，可以把一个物理地址空间映射到不同的进程中，由不同的进程来共享。
1.多线程在单核和多核CPU上的执行效率问题的讨论
a1:多线程在单cpu中其实也是顺序执行的，不过系统可以帮你切换那个执行而已，其实并没有快（反而慢）
多个cpu的话就可以在两个cpu中同时执行了..............
a2:单核CPU上运行的多线程程序, 同一时间只能一个线程在跑, 系统帮你切换线程而已, 系统给每个线程分配时间片来执行, 每个时间片大概10ms左右, 看起来像是同时跑, 但实际上是每个线程跑一点点就换到其它线程继续跑
效率不会有提高的，切换线程反倒会增加开销。
a3:所以一般没有必要的话，尤其在单核CPU的时候，不推荐使用多线程。
单核CPU时使用多线程，通常是有线程要处于等待状态。而对于普通的进度条更新类的，能够简单控制的（比如：在循环里面手动处理消息）就简单控制，一般不使用线程，这样可以提高程序的性能。并且避免掉不必要的线程同步问题。
a4:试一下双核三线程，效率反而比双线程低！
算法同样时，CPU占用率达到100%的最小线程数效率最高，如果是cpu占率率高的运算单核单线程，双核双线程，四核四线程是最适合的。但为什么有时候线程数超过CPU内核数会更快呢？原因是这种程序的单个线程运算量不足以占满CPU一个内核（比如存在大量IO操作，IO比较慢，是程序瓶颈）。
a5:多线程的用处在于，做某个耗时的操作时，需要等待返回结果，这时用多线程可以提高程序并发程度。如果一个不需要任何等待并且顺序执行能够完成的任务，用多线程简直是浪费。
2.浅谈多核CPU、多线程与并行计算
a1: CPU发展趋势
核心数目依旧会越来越多，依据摩尔定律，由于单个核心性能提升有着严重的瓶颈问题，普通的桌面PC有望在2017年末2018年初达到24核心（或者16核32线程），我们如何来面对这突如其来的核心数目的增加？编程也要与时俱进。
a2: 线程越多越好吗？什么时候才有必要用多线程？
线程必然不是越多越好，线程切换也是要开销的，当你增加一个线程的时候，增加的额外开销要小于该线程能够消除的阻塞时间，这才叫物有所值。Linux自从2.6内核开始，就会把不同的线程交给不同的核心去处理。Windows也从NT.4.0开始支持这一特性。
什么时候该使用多线程呢？这要分四种情况讨论：
a.多核CPU：计算密集型任务。此时要尽量使用多线程，可以提高任务执行效率，例如加密解密，数据压缩解压缩（视频、音频、普通数据），否则只能使一个核心满载，而其他核心闲置。
b.单核CPU：计算密集型任务。此时的任务已经把CPU资源100%消耗了，就没必要也不可能使用多线程来提高计算效率了；相反，如果要做人机交互，最好还是要用多线程，避免用户没法对计算机进行操作。
c.单核CPU：IO密集型任务，使用多线程还是为了人机交互方便，
d.多核CPU：IO密集型任务，这就更不用说了，跟单核时候原因一样。
4.程序员需要掌握的技巧/技术
(1)减少串行化的代码用以提高效率。这是废话。
(2)单一的共享数据分布化：把一个数据复制很多份，让不同线程可以同时访问。
(3)负载均衡，分为静态的和动态的两种。具体的参见有关文献。
3.CPU的多核和应用程序的多线程的关系是怎么样的?
a1:多核就是系统同时可以运行多个线程，比如双核可以同时执行两个线程。单核儿只能一次执行一个线程。
a2:试了一个ping 从192.168.0.1 到192.169.0.255的程序用多线程做的，发现在单核的机器上和多核的机器运行性能有两倍左右的差异。
a3:多核对于用户,应该说对于程序员来说,是透明的,根本不用管它,当你是单核的编程就可以了,除非使用OpenMP进行编程,就用很多条条框框了,另外你上面的测试是不准确的,网络(主要是远程主机)会因为不同时候而有不同的响应速度,你应该在干净的本机同环境下进行测试.但是对于多线程多核优于单核还是可以确定的. 总之,我们不用担心程序在单核或多核上会出现并发问题.
a4:多核指的是CPU有多个核心，多线程是程序有多个线程在同时执行。多核也要用多线程才能发挥优势。同样，多线程要在多核上才能真正有优势。这点来说，对程序员不是透明的。程序员可以控制程序/线程在哪个CPU(核)上运行。用户也可以控制程序在哪几个核上运行。所以多核，多线程对用户和程序员都不是透明的。程序员必须了解这方面的知识。才能让程序最大限度的发挥机器的性能。
要实现多任务，通常我们会设计Master-Worker模式，Master负责分配任务，Worker负责执行任务，因此多任务环境下，通常是一个Master，多个Worker。
如果用多进程实现Master-Worker，主进程就是Master，其他进程就是Worker。
如果用多线程实现Master-Worker，主线程就是Master，其他线程就是Worker。
多进程模式最大的优点就是稳定性高，因为一个子进程崩溃了，不会影响主进程和其他子进程。（当然主进程挂了所有进程就全挂了，但是Master进程只负责分配任务，挂掉的概率低）著名的Apache最早就是采用多进程模式。
多进程模式的缺点是创建进程的代价大，在Unix/Linux系统下，用fork调用还行，在Windows下创建进程开销巨大。另外，操作系统能同时运行的进程数也是有限的，在内存和CPU的限制下，如果有几千个进程同时运行，操作系统连调度都会成问题。
多线程模式通常比多进程快一点，但是也快不到哪去，而且多线程模式致命的缺点就是任何一个线程挂掉都可能直接造成整个进程崩溃，因为所有线程共享进程的内存。在Windows上，如果一个线程执行的代码出了问题，其实也就是某个线程出了问题，但是操作系统会强制结束整个进程。
在Windows下，多线程的效率比多进程要高，所以微软的IIS服务器默认采用多线程模式。由于多线程存在稳定性的问题，IIS的稳定性就不如Apache。为了缓解这个问题，IIS和Apache现在又有多进程+多线程的混合模式。
计算密集型与IO密集型
是否采用多任务的第二个考虑是任务的类型。可以把任务分为计算密集型和IO密集型。
计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。对于计算密集型任务，最好用C语言编写。
第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言。
异步IO
考虑到CPU和IO之间巨大的速度差异，一个任务在执行的过程中大部分时间都在等待IO操作，单进程单线程模型会导致别的任务无法并行执行，因此，我们才需要多进程模型或者多线程模型来支持多任务并发执行。
现代操作系统对IO操作已经做了巨大的改进，最大的特点就是支持异步IO。如果充分利用操作系统提供的异步IO支持，就可以用单进程单线程模型来执行多任务，这种全新的模型称为事件驱动模型，Nginx就是支持异步IO的Web服务器，它在单核CPU上采用单进程模型就可以高效地支持多任务。在多核CPU上，可以运行多个进程（数量与CPU核心数相同），充分利用多核CPU。由于系统总的进程数量十分有限，因此操作系统调度非常高效。用异步IO编程模型来实现多任务是一个主要的趋势。
从技术上来优化Web站点
1、减少页面HTTP请求数量
比较直接的理解就是要减少调用其他页面、文件的数量。
A).我们在使用css格式控制的时候，经常会采用background载入很多图形文件，每个background的图像至少产生1次HTTP请求，一般我们为了让页面生动活泼会大量使用background来加载背景图，要改善这个状况，可以采用css的1个有用的background-position属性来加载背景图，我们将需要频繁加载的多个图片合成为1个单独的图片，需要加载时，采用以下形式加载即可将这部分图片加载的HTTP请求缩减为1个。
background:url(....) no-repeat x-offset y-offset;
B).采用Image maps，这个方法也比较常用，只是限于同1个区域使用。
C).Inline images，这个方法很少见到，但对于很小很简单的图像却是很实用的，相关语法标准参照：http://tools.ietf.org/html/rfc2397。
2、使用CDN(Content Delivery Network)网络加速
现在国内做CDN加速业务的公司很多，就是将你的图片、视频扩散到CDN网络所能到达之处，让用户访问时能就近下载到这些文件，从而达到网络提速的目的，这样做同时可减轻你自己网站的负载。
3、添加文件过期或缓存头
对于同一用户频繁访问的图片、Js脚本文件等可以在Apache或Nginx设置其缓冲时间，例如设置24小时过期时间，这样用户在访问过该页面之后再次访问时，同一组图片或JS不会再重复下载，从而减少了HTTP请求，用户访问速度明显有所提升，同时服务器负载也会下降。下面给出nginx配置中缓存控制的例子：
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;#设置30天过期
}
location ~ .*\.(js|css)?$
{
expires 1h;#设置1小时过期
}
4、服务器开启gzip压缩
这个大家都比较了解，即将需要传输的内容压缩后传输到客户端再解压，这样在网络上传输的数据量会大幅减小。通常在服务器上的Apache、Nginx可以直接开启这个设置，也可以从代码角度直接设置传输文件头，增加gzip的设置，也可以从负载均衡设备直接设置。不过需要留意的是，这个设置会略微增加服务器的负担。
5、css格式定义放置在文件头部
这项设置对于用户端是慢速网络或网页内容比较庞大的情况比较有利，可以在网页逐步呈现的同时仍会保持格式信息，不影响网页美感。
6、Javascript脚本放在文件末尾
很多Javascript脚本执行效率低下，或者有的第3方域名脚本出现意外无法载入，如果将这些脚本放置到页面比较靠前的位置，可能会导致我们自己网站的内容载入速度下降甚至无法正常加载，所以一般将这些脚本放置在网页文件末尾，一定要放置在前面的脚本要改用所谓的“后载入”方式加载，在主体网页加载完成后再加载，防止其影响到主体网页的加载速度。
7、避免使用CSS脚本(CSS Expressions)
有时为了要css的参数动态改变，可能会采用css expression来实现，但这样做得不偿失，会使用户端浏览器负担明显加重，所以不建议这样做，如果需要改变，可以使用Javascript脚本去实现。
8、css、javascript改由外部调用
如果css、js内容比较庞大，尽量不要写到同1个页面中去，改由外部载入比较妥当，因为浏览器本身会对css、js文件进行缓存。
9、压缩Javascript、CSS代码
一般js、css文件中存在大量的空格、换行、注释，这些利于阅读，如果能够压缩掉，将会很有利于网络传输。这方面的工具也有很多，一般可以保留开发版本，利用工具生成生产版本，2个文件比较，一般压缩率能达到50%以上，减少的数据量还是比较可观的。
10、避免采用301、302转向
11、养成良好的开发维护习惯，尽量避免脚本重复调用
12、配置ETags
13、Ajax采用缓存调用
这个的使用可以参照Discuz论坛代码，里面对于大量使用的Ajax调用都采用了缓存调用方式，一般采用附加特征参数方式实现，注意其中的 script src="”xxx.js?{VERHASH}”，{VERHASH}就是特征参数，这个参数不变化就使用缓存文件，如果发生变化则重新下载新文件或更新信息。
14、合理使用Flush
用户端发送浏览请求后，服务器端一般要花销200-500ms去处理这些请求，在此期间，用户端浏览器处于等待状态，如果要减少用户等待时间，可以在适当的位置使用flush，将已经就绪的内容推送到用户端，这在php中很容易实现。
15、Ajax调用尽量采用GET方法调用
实际使用XMLHttpRequest时，如果使用POST方法实现，会发生2次HTTP请求，而使用GET方法只会发生1次HTTP请求。如果改用GET方法，HTTP请求减少50%！
16、尽可能减少DCOM元素
这个很好理解，就是尽可能减少网页中各种元素数量，例如'p'、'table border="0"' 的冗余很严重，而我们完全可以用 'div'取代之。
17、使用多域名负载网页内的多个文件、图片
有资料说明，IE在网页载入过程中，在同一时刻，对同一域名并行请求的HTTP请求数量最高为2个，如果网页需要加载的文件数量超过2个(通常远远超过..)，要加快网页访问速度，最好将文件分布到多个域名，例如19楼，其js文件采用独立的域名，据说百度的图片服务器数量在20台以上。
18、缩减iframe的使用，如无必要，尽量不要使用
iframe通常用于不同域名内容的加载，这同时也可能因iframe内容加载速度影响到主网页加载速度，如果可能，把需要加载的内容抓取到本地直接嵌入。如果实在需要iframe加载，采用后载入方式实现。
19、优化图片文件
优化图片文件，减小其尺寸，特别是缩略图，一定要按尺寸生成缩略图然后调用，不要在网页中用resize方法实现；虽然这样看到的图片外形笑了，但是其加载的数据量一点也没减少。曾经见过有人在网页中加载的缩略图，其真实尺寸有10M之巨。普通图像、icon也要尽可能压缩后，可以采用web图像保存、减少颜色数等等方法实现。
20、当页面内容庞大到一定程度，可以采用分页的方式展现，或者利用翻页后载入的方法。
什么是服务器并发处理能力：一台服务器在单位时间里能处理的请求越多，服务器的能力越高，也就是服务器并发处理能力越强，有什么方法衡量服务器并发处理能力呢？
1. 吞吐率
吞吐率，单位时间里服务器处理的最大请求数，单位req/s。
从服务器角度，实际并发用户数的可以理解为服务器当前维护的代表不同用户的文件描述符总数，也就是并发连接数。服务器一般会限制同时服务的最多用户数，比如apache的MaxClents参数。
这里再深入一下，对于服务器来说，服务器希望支持高吞吐率，对于用户来说，用户只希望等待最少的时间，显然双方不能满足，所以双方利益的平衡点，就是我们希望的最大并发用户数。
2. 压力测试
有一个原理一定要先搞清楚，假如100个用户同时向服务器分别进行10个请求，与1个用户向服务器连续进行1000次请求，对服务器的压力是一样吗？
实际上是不一样的，因对每一个用户，连续发送请求实际上是指发送一个请求并接收到响应数据后再发送下一个请求。这样对于1个用户向服务器连续进行1000次请求，任何时刻服务器的网卡接收缓冲区中只有1个请求，而对于100个用户同时向服务器分别进行10个请求，服务器的网卡接收缓冲区最多有100个等待处理的请求，显然这时的服务器压力更大。
压力测试前提考虑的条件
并发用户数: 指在某一时刻同时向服务器发送请求的用户总数(HttpWatch)
总请求数
请求资源描述
请求等待时间(用户等待时间)
用户平均请求的等待时间
服务器平均请求处理的时间
硬件环境
压力测试中关心的时间又细分以下2种:
用户平均请求等待时间（这里暂不把数据在网络的传输时间，还有用户PC本地的计算时间计算入内）
服务器平均请求处理时间
用户平均请求等待时间主要用于衡量服务器在一定并发用户数下，单个用户的服务质量；而服务器平均请求处理时间就是吞吐率的倒数。一般来说，用户平均请求等待时间 = 服务器平均请求处理时间 * 并发用户数
怎么提高服务器的并发处理能力
1. 提高CPU并发计算能力
服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计使得多个任务可以轮流使用系统资源。
这些资源包括CPU，内存以及I/O. 这里的I/O主要指磁盘I/O, 和网络I/O。
多进程 & 多线程
多执行流的一般便是进程，多进程的好处可以对CPU时间的轮流使用，对CPU计算和IO操作重叠利用。这里的IO主要是指磁盘IO和网络IO，相对CPU而言，它们慢的可怜。而实际上，大多数进程的时间主要消耗在I/O操作上。
现代计算机的DMA技术可以让CPU不参与I/O操作的全过程，比如进程通过系统调用，使得CPU向网卡或者磁盘等I/O设备发出指令，然后进程被挂起，释放出CPU资源，等待I/O设备完成工作后通过中断来通知进程重新就绪。
对于单任务而言，CPU大部分时间空闲，这时候多进程的作用尤为重要。多进程不仅能够提高CPU的并发度。其优越性还体现在独立的内存地址空间和生命周期所带来的稳定性和健壮性，其中一个进程崩溃不会影响到另一个进程。但是进程也有如下缺点：
fork()系统调用开销很大：prefork
进程间调度和上下文切换成本：减少进程数量
庞大的内存重复：共享内存
IPC编程相对比较麻烦
减少进程切换
当硬件上下文频繁装入和移出时，所消耗的时间是非常可观的。可用Nmon或sysstate工具监视服务器每秒的上下文切换次数。为了尽量减少上下文切换次数，最简单的做法就是减少进程数，尽量使用线程并配合其它I/O模型来设计并发策略。
还可以考虑使用进程绑定CPU技术，增加CPU缓存的命中率。若进程不断在各CPU上切换，这样旧的CPU缓存就会失效。
减少使用不必要的锁
服务器处理大量并发请求时，多个请求处理任务时存在一些资源抢占竞争，这时一般采用“锁”机制来控制资源的占用。当一个任务占用资源时，我们锁住资源，这时其它任务都在等待锁的释放，这个现象称为锁竞争。
通过锁竞争的本质，我们要意识到尽量减少并发请求对于共享资源的竞争。比如在允许情况下关闭服务器访问日志，这可以大大减少在锁等待时的延迟时间。要最大程度减少无辜的等待时间。
这里说下无锁编程，就是由内核完成这个锁机制，主要是使用原子操作替代锁来实现对共享资源的访问保护。使用原子操作时，在进行实际的写操作时，使用了lock指令，这样就可以阻止其他任务写这块内存，避免出现数据竞争现象。原子操作速度比锁快，一般要快一倍以上。
例如fwrite(), fopen()，其是使用append方式写文件，其原理就是使用了无锁编程，无锁编程的复杂度高，但是效率快，而且发生死锁概率低。
考虑进程优先级
进程调度器会动态调整运行队列中进程的优先级，通过top观察进程的PR值。
考虑系统负载
可在任何时刻查看/proc/loadavg, top中的load average也可看出。
考虑CPU使用率
除了用户空间和内核空间的CPU使用率以外，还要关注I/O wait,它是指CPU空闲并且等待I/O操作完成的时间比例(top中查看wa的值)。
2. 考虑减少内存分配和释放
服务器的工作过程中，需要大量的内存，使得内存的分配和释放工作尤为重要。可以通过改善数据结构和算法复制度来适当减少中间临时变量的内存分配及数据复制时间，而服务器本身也使用了各自的策略来提高效率。
例如Apache在运行开始时一次申请大片的内存作为内存池，若随后需要时就在内存池中直接获取，不需要再次分配，避免了频繁的内存分配和释放引起的内存整理时间。再如Nginx使用事件来处理请求，使得多个'worker'之间可以共享内存资源，从而令它的内存总体使用量大大减少。Nginx分阶段的内存分配策略，按需分配，及时释放，使得内存使用量保持在很小的数量范围。
另外，还可以考虑共享内存。
共享内存指在多处理器的计算机系统中，可以被不同中央处理器（CPU）访问的大容量内存，也可以由不同进程共享，是非常快的进程通信方式。但是使用共享内存也有不好的地方，就是对于多机器时数据不好统一。
shell命令ipcs可用来显示系统下共享内存的状态，函数shmget可以创建或打开一块共享内存区，函数shmat将一个存在的共享内存段连接到本进程空间，函数shmctl可以对共享内存段进行多种操作，函数shmdt函数分离该共享内存。
3. 考虑使用持久连接
持久连接也为长连接，它本身是TCP通信的一种普通方式，即在一次TCP连接中持续发送多分数据而不断开连接。与它相反的方式称为短连接，也就是建立连接后发送一份数据就断开，然后再次建立连接发送下一份数据， 周而复始。
是否采用持久连接，完全取决于应用特点。
从性能角度看，建立TCP连接的操作本身是一项不小的开销，在允许的情况下，连接次数越少，越有利于性能的提升；尤其对于密集型的图片或网页等小数据请求处理有明显的加速所用。HTTP长连接需要浏览器和web服务器的共同协作，目前浏览器普遍支持长连接，表现在其发出的HTTP请求数据头中包含关于长连接的声明，如下：Connection: Keep-Alive
主流的web服务器都支持长连接，比如apache中，可以用KeepAlive off关闭长连接。对于长连接的有效使用，还有关键一点在于长连接超时时间的设置，即长连接在什么时候关闭吗？
Apache的默认设置为5s, 若这个时间设置过长，则可能导致资源无效占有，维持大量空闲进程，影响服务器性能。
4. 改进I/O 模型
I/O操作根据设备的不同分为很多类型，比如内存I/O, 网络I/O, 磁盘I/O。
对于网络I/O和磁盘I/O，它们的速度要慢很多，尽管使用RAID磁盘阵列可通过并行磁盘磁盘来加快磁盘I/O速度，购买独享网络带宽以及使用高带宽网络适配器可以提高网络I/O的速度。
但这些I/O操作需要内核系统调用来完成，这些需要CPU来调度，这使得CPU不得不浪费宝贵的时间来等待慢速I/O操作。
我们希望让CPU足够少的时间在i/O操作的调度上，如何让高速的CPU和慢速的I/O设备更好地协调工作，是现代计算机一直探讨的话题。各种I/O模型的本质区别在于CPU的参与方式。
DMA技术
I/O设备和内存之间的数据传输方式由DMA控制器完成。在DMA模式下，CPU只需向DMA下达命令，让DMA控制器来处理数据的传送，这样可以大大节省系统资源。
异步I/O
异步I/O指主动请求数据后便可以继续处理其它任务，随后等待I/O操作的通知，这样进程在数据读写时不发生阻塞。异步I/O是非阻塞的，当函数返回时，真正的I/O传输已经完成，这让CPU处理和I/O操作达到很好的重叠。
I/O多路复用
epoll服务器同时处理大量的文件描述符是必不可少的，若采用同步非阻塞I/O模型，若同时接收TCP连接的数据，就必须轮流对每个socket调用接收数据的方法，不管这些socket有没有可接收的数据，都要询问一次。
假如大部分socket并没有数据可以接收，那么进程便会浪费很多CPU时间用于检查这些socket有没有可以接收的数据。多路I/O就绪通知的出现，提供了对大量文件描述符就绪检查的高性能方案，它允许进程通过一种方法同时监视所有文件描述符，并可以快速获得所有就绪的文件描述符，然后只针对这些文件描述符进行数据访问。
epoll可以同时支持水平触发和边缘触发，理论上边缘触发性能更高，但是代码实现复杂，因为任何意外的丢失事件都会造成请求处理错误。epoll主要有2大改进：
epoll只告知就绪的文件描述符，而且当调用epoll_wait()获得文件描述符时，返回并不是实际的描述符，而是一个代表就绪描述符数量的值，然后只需去epoll指定的一个数组中依次取得相应数量的文件描述符即可。
这里使用了内存映射(mmap)技术，这样彻底省掉了这些文件描述符在系统调用时复制的开销。
epoll采用基于事件的就绪通知方式。其事先通过epoll_ctrl()注册每一个文件描述符，一旦某个文件描述符就绪时，内核会采用类似callback的回调机制，当进程调用epoll_wait()时得到通知。
Sendfile
大多数时候，我们都向服务器请求静态文件，比如图片，样式表等。在处理这些请求时，磁盘文件的数据先经过内核缓冲区，然后到用户内存空间，不需经过任何处理，其又被送到网卡对应的内核缓冲区，接着再被送入网卡进行发送。
Linux提供sendfile()系统调用，可以讲磁盘文件的特定部分直接传送到代表客户端的socket描述符，加快了静态文件的请求速度，同时减少CPU和内存的开销。
适用场景：对于请求较小的静态文件，sendfile发挥的作用不那么明显，因发送数据的环节在整个过程中所占时间的比例相比于大文件请求时小很多。
内存映射
Linux内核提供一种访问磁盘文件的特殊方式，它可以将内存中某块地址空间和我们指定的磁盘文件相关联，从而对这块内存的访问转换为对磁盘文件的访问。这种技术称为内存映射。
多数情况下，内存映射可以提高磁盘I/O的性能，无须使用read()或write()等系统调用来访问文件，而是通过mmap()系统调用来建立内存和磁盘文件的关联，然后像访问内存一样自由访问文件。
缺点：在处理较大文件时，内存映射会导致较大的内存开销，得不偿失。
直接I/O
在linux 2.6中，内存映射和直接访问文件没有本质差异，因为数据需要经过2次复制，即在磁盘与内核缓冲区之间以及在内核缓冲区与用户态内存空间。引入内核缓冲区的目的在于提高磁盘文件的访问性能，然而对于一些复杂的应用，比如数据库服务器，它们为了进一步提高性能，希望绕过内核缓冲区，由自己在用户态空间实现并管理I/O缓冲区，比如数据库可根据更加合理的策略来提高查询缓存命中率。
另一方面，绕过内核缓冲区也可以减少系统内存的开销，因内核缓冲区本身就在使用系统内存。
Linux在open()系统调用中增加参数选项O_DIRECT,即可绕过内核缓冲区直接访问文件,实现直接I/O。
在Mysql中，对于Innodb存储引擎，自身进行数据和索引的缓存管理，可在my.cnf配置中分配raw分区跳过内核缓冲区，实现直接I/O。
5. 改进服务器并发策略
服务器并发策略的目的，是让I/O操作和CPU计算尽量重叠进行，一方面让CPU在I/O等待时不要空闲，另一方面让CPU在I/O调度上尽量花最少的时间。
一个进程处理一个连接，非阻塞I/O
这样会存在多个并发请求同时到达时，服务器必然要准备多个进程来处理请求。其进程的开销限制了它的并发连接数。但从稳定性和兼容性的角度，则其相对安全，任何一个子进程的崩溃不会影响服务器本身，父进程可以创建新的子进程；这种策略典型的例子就是Apache的fork和prefork模式。对于并发数不高（如150以内）的站点同时依赖Apache其它功能时的应用选择Apache还是可以的。
一个线程处理一个连接，非阻塞IO
这种方式允许在一个进程中通过多个线程来处理多个连接，一个线程处理一个连接。Apache的worker模式就是这种典型例子，使其可支持更多的并发连接。不过这种模式的总体性能还不如prefork，所以一般不选用worker模式。
一个进程处理多个连接，异步I/O
一个线程同时处理多个连接，潜在的前提条件就是使用IO多路复用就绪通知。这种情况下，将处理多个连接的进程叫做worker进程或服务进程。worker的数量可以配置，如Nginx中的worker_processes 4。
一个线程处理多个连接，异步IO
即使有高性能的IO多路复用就绪通知，但磁盘IO的等待还是无法避免的。更加高效的方法是对磁盘文件使用异步IO，目前很少有Web服务器真正意义上支持这种异步IO。
6. 改进硬件环境
还有一点要提及的是硬件环境，服务器的硬件配置对应用程序的性能提升往往是最直接，也是最简单的方式，这就是所谓的scale up。
多进、线程程序在CPU上是如何工作的
此文中的大部分资料来自于网络上，只是觉得把有道理的整理一下，方便以后查阅。
线程与进程
进程：可以理解成一个程序，是占有一定Cpu资源、它是系统进行资源分配和调度的一个独立单位，重点在系统调度和单独的单位，也就是说进程是可以独立运行的一段程序。比如说，运行火狐浏览器就是一个进程。
线程：一个进程至少有一个线程。线程是CPU的实际调度和分派的基本单位，他是比进程更小的能独立运行的基本单位，线程自己基本上不拥有系统资源。比如说浏览器，它就有很多的线程，每一个标签就是一个新的线程，这些线程共享占用着进程所占有的系统资源。
超线程：假如说我有个单核的CPU，我要是想要运行一个多线程的程序，通常情况下，只能是由Cpu在线程之间来回调度，但是当我开启了超线程，我可以在一个线程执行整数指令集的时候，而恰好在这个时候，另一个线程执行浮点指令集，而这两个指令集分数与整数指令单元和浮点指令单元来执行。那么我就可以同时执行这两个线程，这就叫超线程。而且实际上，是有大量资源被闲置着的。超线程技术允许两个线程同时不冲突地使用CPU中的资源。指令单元闲置，可以通过超线程的技术来达到提高利用率。这叫做硬件多线程技术。
CPU 工作的分配一般是以线程为级别的，只不过大部分程序一个进程只用一个线程，所以看起来好像 CPU 只能是以进程位粒度分配任务。进程是组织资源的最小单位，而线程是安排 CPU 执行的最小单位，一个逻辑 CPU 核心在某一时刻只能 hold 住一个线程。多线程当然可以利用多核，调度单元是线程，不是进程。
并发(concurrent)与并行(parallel)的区别，最早 UNIX 的调度是以 “进程” 为最小调度单位，那个时候还没有线程的概念。线程有两种，一种是 “用户态线程” ，对内核不可见，内核不可以调度，现在一般叫做线程或协程。另一种是 “内核态线程”，由内核调度，也称作轻量进程 LWP 。现在说的线程，一般不特殊指定，都是内核线程。多进程由于要 fork 两份一模一样的数据，并且要 CPU 要切换进程，也会耗费不少资源。
能不能利用多核的关键是能不能被内核调度，既然内核态线程可以被调度，自然可以利用多核。另外只要资源足够（内存） CPU 可以 hold 住任意多的进程或线程，这与 CPU 的核数无关。
CPU核数跟多线程的关系
要说多线程就离不开进程，进程和线程的区别在这里就不详细说了，只将关键的几点：
a)进程之间是相互独立的，不共享内存和数据，线程之间的内存和数据是公用的，每个线程只有自己的一组CPU指令、寄存器和堆栈，对于线程来说只有CPU里的东西是自己独享的，程序中的其他东西都是跟同一个进程里的其他线程共享的。
b)操作系统创建进程时要分配好多外部资源，所以开销大（这个跟操作系统有关，有人做过实验，Windows创建进程的开销大，Linux创建进程的开销就很小。）
再来说一下CPU，过去单CPU时代，最先是单任务阶段在一个时间点只能执行单一程序。之后发展到多任务阶段，计算机能在同一时间点并行执行多任务或多进程。虽然并不是真正意义上的“同一时间点”，而是多个任务或进程共享一个CPU，并交由操作系统来完成多任务间对CPU的运行切换，以使得每个任务都有机会获得一定的时间片运行。而现在多核CPU的情况下，同一时间点可以执行多个任务(并行)，具体到这个任务在CPU哪个核上运行，这个就跟操作系统和CPU本身的设计相关了。
假设一个极端的情况：在一台单核计算机上只运行2个程序，一个是我们的程序A，另一个是操作系统的程序B，每个程序是一个进程。单核CPU的时候，A和B在CPU上交替运行，具体的分配方式由操作系统来判断，这里猜测应该跟A和B的线程数有关，因为线程是CPU级别的，如果A有5个线程，B也有5个线程，那么CPU分配给A和B的时间应该是1：1的；如果A增加到15个线程，CPU分配给A和B的时间应该是3：1的比例。所以此时如果A的线程数多，那么获得的CPU执行次数就多，处理的速度也就快了。以上假设的前提是：①A和B的优先级相同，②A和B都是只消耗CPU资源的程序。
如果相同的情况用一个双核的计算机来处理又会是什么结果呢？假设这个双核的计算机和操作系统比较傻，把A进程分配到核1上，B进程分配到核2上，那不管A有几个线程，都是用核1来处理，那么时间肯定是一样的。不过现实中应该不会有这么傻的CPU和操作系统吧。所以赶紧还是会根据线程来进行处理，当A的线程比B多时，会占用核2来处理A的线程。
刚才说的是只消耗CPU资源的程序，但这样的程序在实际应用中基本上是没有的，总会有跟资源打交道的。比如读个文件，查个数据库，访问一个网络连接等等。这个时候多线程才真正体现出优势，在一个进程中，线程a去读文件，线程b去查数据库，线程c去访问网络，a先用一下CPU，然后去读文件，此时CPU空闲，b就用一下，然后去查数据库，……，相对于读文件、查数据库、访问网络来说CPU计算的时间几乎可以忽略不计，所以多线程实际上是计算机多种资源的并行运用，跟CPU有几个核心是没什么关系的。
CPU组件
1.在单核计算机里，有一个资源是无法被多个程序并行使用的：CPU。
没有操作系统的情况下，一个程序一直独占着全都CPU。如果要有两个任务来共享同一个CPU，程序员就需要仔细地为程序安排好运行计划–某时刻cpu和由程序A来独享，下一时刻cpu由程序B来独享，而这种安排计划后来成为OS的核心组件，被单独名命为“scheduler”，即“调度器”，它关心的只是怎样把单个CPU的运行拆分成一段一段的“运行片”，轮流分给不同的程序去使用，而在宏观上，因为分配切换的速度极快，就制造出多程序并行在一个CPU上的假象。
2.在单核计算机里，有一个资源可以被多个程序共用，然而会引出麻烦：内存。
在一个只有调度器，没有内存管理组件的操作系统上，程序员需要手工为每个程序安排运行的空间 — 程序A使用物理地址0x00-0xff,程序B使用物理地址0x100-0x1ff，等等。然而这样做有个很大的问题：每个程序都要协调商量好怎样使用同一个内存上的不同空间，软件系统和硬件系统千差万别，使这种定制的方案没有可行性。为了解决这个麻烦，计算机系统引入了“虚拟地址”的概念，从三方面入手来做：
2.1、硬件上，CPU增加了一个专门的模块叫MMU，负责转换虚拟地址和物理地址。
2.2、操作系统上，操作系统增加了另一个核心组件：memory management，即内存管理模块，它管理物理内存、虚拟内存相关的一系列事务。
2.3、应用程序上，发明了一个叫做“进程”的模型，（注意）每个进程都用“完全一样的”虚拟地址空间，然而经由操作系统和硬件MMU协作，映射到不同的物理地址空间上。不同的“进程”，都有各自独立的物理内存空间，不用一些特殊手段，是无法访问别的进程的物理内存的。
3.现在，不同的应用程序，可以不关心底层的物理内存分配，也不关心CPU的协调共享了。然而还有一个问题存在：有一些程序，想要共享CPU，并且还要共享同样的物理内存，这时候，一个叫“线程”的模型就出现了，它们被包裹在进程里面，在调度器的管理下共享CPU，拥有同样的虚拟地址空间，同时也共享同一个物理地址空间，然而，它们无法越过包裹自己的进程，去访问别一个进程的物理地址空间。
4.进程之间怎样共享同一个物理地址空间呢？不同的系统方法各异，符合posix规范的操作系统都提供了一个接口，叫mmap，可以把一个物理地址空间映射到不同的进程中，由不同的进程来共享。
1.多线程在单核和多核CPU上的执行效率问题的讨论
a1:多线程在单cpu中其实也是顺序执行的，不过系统可以帮你切换那个执行而已，其实并没有快（反而慢）
多个cpu的话就可以在两个cpu中同时执行了..............
a2:单核CPU上运行的多线程程序, 同一时间只能一个线程在跑, 系统帮你切换线程而已, 系统给每个线程分配时间片来执行, 每个时间片大概10ms左右, 看起来像是同时跑, 但实际上是每个线程跑一点点就换到其它线程继续跑
效率不会有提高的，切换线程反倒会增加开销。
a3:所以一般没有必要的话，尤其在单核CPU的时候，不推荐使用多线程。
单核CPU时使用多线程，通常是有线程要处于等待状态。而对于普通的进度条更新类的，能够简单控制的（比如：在循环里面手动处理消息）就简单控制，一般不使用线程，这样可以提高程序的性能。并且避免掉不必要的线程同步问题。
a4:试一下双核三线程，效率反而比双线程低！
算法同样时，CPU占用率达到100%的最小线程数效率最高，如果是cpu占率率高的运算单核单线程，双核双线程，四核四线程是最适合的。但为什么有时候线程数超过CPU内核数会更快呢？原因是这种程序的单个线程运算量不足以占满CPU一个内核（比如存在大量IO操作，IO比较慢，是程序瓶颈）。
a5:多线程的用处在于，做某个耗时的操作时，需要等待返回结果，这时用多线程可以提高程序并发程度。如果一个不需要任何等待并且顺序执行能够完成的任务，用多线程简直是浪费。
2.浅谈多核CPU、多线程与并行计算
a1: CPU发展趋势
核心数目依旧会越来越多，依据摩尔定律，由于单个核心性能提升有着严重的瓶颈问题，普通的桌面PC有望在2017年末2018年初达到24核心（或者16核32线程），我们如何来面对这突如其来的核心数目的增加？编程也要与时俱进。
a2: 线程越多越好吗？什么时候才有必要用多线程？
线程必然不是越多越好，线程切换也是要开销的，当你增加一个线程的时候，增加的额外开销要小于该线程能够消除的阻塞时间，这才叫物有所值。Linux自从2.6内核开始，就会把不同的线程交给不同的核心去处理。Windows也从NT.4.0开始支持这一特性。
什么时候该使用多线程呢？这要分四种情况讨论：
a.多核CPU：计算密集型任务。此时要尽量使用多线程，可以提高任务执行效率，例如加密解密，数据压缩解压缩（视频、音频、普通数据），否则只能使一个核心满载，而其他核心闲置。
b.单核CPU：计算密集型任务。此时的任务已经把CPU资源100%消耗了，就没必要也不可能使用多线程来提高计算效率了；相反，如果要做人机交互，最好还是要用多线程，避免用户没法对计算机进行操作。
c.单核CPU：IO密集型任务，使用多线程还是为了人机交互方便，
d.多核CPU：IO密集型任务，这就更不用说了，跟单核时候原因一样。
4.程序员需要掌握的技巧/技术
(1)减少串行化的代码用以提高效率。这是废话。
(2)单一的共享数据分布化：把一个数据复制很多份，让不同线程可以同时访问。
(3)负载均衡，分为静态的和动态的两种。具体的参见有关文献。
3.CPU的多核和应用程序的多线程的关系是怎么样的?
a1:多核就是系统同时可以运行多个线程，比如双核可以同时执行两个线程。单核儿只能一次执行一个线程。
a2:试了一个ping 从192.168.0.1 到192.169.0.255的程序用多线程做的，发现在单核的机器上和多核的机器运行性能有两倍左右的差异。
a3:多核对于用户,应该说对于程序员来说,是透明的,根本不用管它,当你是单核的编程就可以了,除非使用OpenMP进行编程,就用很多条条框框了,另外你上面的测试是不准确的,网络(主要是远程主机)会因为不同时候而有不同的响应速度,你应该在干净的本机同环境下进行测试.但是对于多线程多核优于单核还是可以确定的. 总之,我们不用担心程序在单核或多核上会出现并发问题.
a4:多核指的是CPU有多个核心，多线程是程序有多个线程在同时执行。多核也要用多线程才能发挥优势。同样，多线程要在多核上才能真正有优势。这点来说，对程序员不是透明的。程序员可以控制程序/线程在哪个CPU(核)上运行。用户也可以控制程序在哪几个核上运行。所以多核，多线程对用户和程序员都不是透明的。程序员必须了解这方面的知识。才能让程序最大限度的发挥机器的性能。
要实现多任务，通常我们会设计Master-Worker模式，Master负责分配任务，Worker负责执行任务，因此多任务环境下，通常是一个Master，多个Worker。
如果用多进程实现Master-Worker，主进程就是Master，其他进程就是Worker。
如果用多线程实现Master-Worker，主线程就是Master，其他线程就是Worker。
多进程模式最大的优点就是稳定性高，因为一个子进程崩溃了，不会影响主进程和其他子进程。（当然主进程挂了所有进程就全挂了，但是Master进程只负责分配任务，挂掉的概率低）著名的Apache最早就是采用多进程模式。
多进程模式的缺点是创建进程的代价大，在Unix/Linux系统下，用fork调用还行，在Windows下创建进程开销巨大。另外，操作系统能同时运行的进程数也是有限的，在内存和CPU的限制下，如果有几千个进程同时运行，操作系统连调度都会成问题。
多线程模式通常比多进程快一点，但是也快不到哪去，而且多线程模式致命的缺点就是任何一个线程挂掉都可能直接造成整个进程崩溃，因为所有线程共享进程的内存。在Windows上，如果一个线程执行的代码出了问题，其实也就是某个线程出了问题，但是操作系统会强制结束整个进程。
在Windows下，多线程的效率比多进程要高，所以微软的IIS服务器默认采用多线程模式。由于多线程存在稳定性的问题，IIS的稳定性就不如Apache。为了缓解这个问题，IIS和Apache现在又有多进程+多线程的混合模式。
计算密集型与IO密集型
是否采用多任务的第二个考虑是任务的类型。可以把任务分为计算密集型和IO密集型。
计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。对于计算密集型任务，最好用C语言编写。
第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言。
异步IO
考虑到CPU和IO之间巨大的速度差异，一个任务在执行的过程中大部分时间都在等待IO操作，单进程单线程模型会导致别的任务无法并行执行，因此，我们才需要多进程模型或者多线程模型来支持多任务并发执行。
现代操作系统对IO操作已经做了巨大的改进，最大的特点就是支持异步IO。如果充分利用操作系统提供的异步IO支持，就可以用单进程单线程模型来执行多任务，这种全新的模型称为事件驱动模型，Nginx就是支持异步IO的Web服务器，它在单核CPU上采用单进程模型就可以高效地支持多任务。在多核CPU上，可以运行多个进程（数量与CPU核心数相同），充分利用多核CPU。由于系统总的进程数量十分有限，因此操作系统调度非常高效。用异步IO编程模型来实现多任务是一个主要的趋势。
从技术上来优化Web站点
1、减少页面HTTP请求数量
比较直接的理解就是要减少调用其他页面、文件的数量。
A).我们在使用css格式控制的时候，经常会采用background载入很多图形文件，每个background的图像至少产生1次HTTP请求，一般我们为了让页面生动活泼会大量使用background来加载背景图，要改善这个状况，可以采用css的1个有用的background-position属性来加载背景图，我们将需要频繁加载的多个图片合成为1个单独的图片，需要加载时，采用以下形式加载即可将这部分图片加载的HTTP请求缩减为1个。
background:url(....) no-repeat x-offset y-offset;
B).采用Image maps，这个方法也比较常用，只是限于同1个区域使用。
C).Inline images，这个方法很少见到，但对于很小很简单的图像却是很实用的，相关语法标准参照：http://tools.ietf.org/html/rfc2397。
2、使用CDN(Content Delivery Network)网络加速
现在国内做CDN加速业务的公司很多，就是将你的图片、视频扩散到CDN网络所能到达之处，让用户访问时能就近下载到这些文件，从而达到网络提速的目的，这样做同时可减轻你自己网站的负载。
3、添加文件过期或缓存头
对于同一用户频繁访问的图片、Js脚本文件等可以在Apache或Nginx设置其缓冲时间，例如设置24小时过期时间，这样用户在访问过该页面之后再次访问时，同一组图片或JS不会再重复下载，从而减少了HTTP请求，用户访问速度明显有所提升，同时服务器负载也会下降。下面给出nginx配置中缓存控制的例子：
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;#设置30天过期
}
location ~ .*\.(js|css)?$
{
expires 1h;#设置1小时过期
}
4、服务器开启gzip压缩
这个大家都比较了解，即将需要传输的内容压缩后传输到客户端再解压，这样在网络上传输的数据量会大幅减小。通常在服务器上的Apache、Nginx可以直接开启这个设置，也可以从代码角度直接设置传输文件头，增加gzip的设置，也可以从负载均衡设备直接设置。不过需要留意的是，这个设置会略微增加服务器的负担。
5、css格式定义放置在文件头部
这项设置对于用户端是慢速网络或网页内容比较庞大的情况比较有利，可以在网页逐步呈现的同时仍会保持格式信息，不影响网页美感。
6、Javascript脚本放在文件末尾
很多Javascript脚本执行效率低下，或者有的第3方域名脚本出现意外无法载入，如果将这些脚本放置到页面比较靠前的位置，可能会导致我们自己网站的内容载入速度下降甚至无法正常加载，所以一般将这些脚本放置在网页文件末尾，一定要放置在前面的脚本要改用所谓的“后载入”方式加载，在主体网页加载完成后再加载，防止其影响到主体网页的加载速度。
7、避免使用CSS脚本(CSS Expressions)
有时为了要css的参数动态改变，可能会采用css expression来实现，但这样做得不偿失，会使用户端浏览器负担明显加重，所以不建议这样做，如果需要改变，可以使用Javascript脚本去实现。
8、css、javascript改由外部调用
如果css、js内容比较庞大，尽量不要写到同1个页面中去，改由外部载入比较妥当，因为浏览器本身会对css、js文件进行缓存。
9、压缩Javascript、CSS代码
一般js、css文件中存在大量的空格、换行、注释，这些利于阅读，如果能够压缩掉，将会很有利于网络传输。这方面的工具也有很多，一般可以保留开发版本，利用工具生成生产版本，2个文件比较，一般压缩率能达到50%以上，减少的数据量还是比较可观的。
10、避免采用301、302转向
11、养成良好的开发维护习惯，尽量避免脚本重复调用
12、配置ETags
13、Ajax采用缓存调用
这个的使用可以参照Discuz论坛代码，里面对于大量使用的Ajax调用都采用了缓存调用方式，一般采用附加特征参数方式实现，注意其中的 script src="”xxx.js?{VERHASH}”，{VERHASH}就是特征参数，这个参数不变化就使用缓存文件，如果发生变化则重新下载新文件或更新信息。
14、合理使用Flush
用户端发送浏览请求后，服务器端一般要花销200-500ms去处理这些请求，在此期间，用户端浏览器处于等待状态，如果要减少用户等待时间，可以在适当的位置使用flush，将已经就绪的内容推送到用户端，这在php中很容易实现。
15、Ajax调用尽量采用GET方法调用
实际使用XMLHttpRequest时，如果使用POST方法实现，会发生2次HTTP请求，而使用GET方法只会发生1次HTTP请求。如果改用GET方法，HTTP请求减少50%！
16、尽可能减少DCOM元素
这个很好理解，就是尽可能减少网页中各种元素数量，例如'p'、'table border="0"' 的冗余很严重，而我们完全可以用 'div'取代之。
17、使用多域名负载网页内的多个文件、图片
有资料说明，IE在网页载入过程中，在同一时刻，对同一域名并行请求的HTTP请求数量最高为2个，如果网页需要加载的文件数量超过2个(通常远远超过..)，要加快网页访问速度，最好将文件分布到多个域名，例如19楼，其js文件采用独立的域名，据说百度的图片服务器数量在20台以上。
18、缩减iframe的使用，如无必要，尽量不要使用
iframe通常用于不同域名内容的加载，这同时也可能因iframe内容加载速度影响到主网页加载速度，如果可能，把需要加载的内容抓取到本地直接嵌入。如果实在需要iframe加载，采用后载入方式实现。
19、优化图片文件
优化图片文件，减小其尺寸，特别是缩略图，一定要按尺寸生成缩略图然后调用，不要在网页中用resize方法实现；虽然这样看到的图片外形笑了，但是其加载的数据量一点也没减少。曾经见过有人在网页中加载的缩略图，其真实尺寸有10M之巨。普通图像、icon也要尽可能压缩后，可以采用web图像保存、减少颜色数等等方法实现。
20、当页面内容庞大到一定程度，可以采用分页的方式展现，或者利用翻页后载入的方法。
该文章最后由 阿炯 于 2025-07-21 11:58:35 更新，目前是第 2 版。