我觉得服务器在成为大并发前，首先要能承受住大并发的压力，无论能否正常返回，首先不能崩溃。

apache和nginx是两个出名的服务器，先来分析一下它们。

大量用户访问的时候，apache会创建大量的进程数，吃掉大量的内存，而nginx内存这块做得很好，不过这也是nginx的瓶颈所在。

所谓有内存就是给你花的，你不花怎么对得起服务器呢，何况现在的服务器一般都是高配。

快速响应与内存大小其实是两个极端，apache与nginx正好在这两个极端上。

apache ?为每一个connection 分配一个进程，当connection 井喷时，进程数也随之井喷。

nginx 的进程由用户设置，单个worker进程就可以处理用户所有的事件，epoll_wait 返回大量事件(A,B,C,D,E)时，服务器会顺序执行的所有的事件，事件A没有处理完，

E是不能执行的，也不用同时分配内存，这样就避免内存井喷的现象，当事件处理粒度大的时候，性能就出现瓶颈了。

apache 的优点在于进程数的可伸缩性，随着连接数的变化而变化，缺点在于连接数大时会吃掉太多内存。

nginx优点在于所用内存很少，但是事件需要顺序执行，伸缩性上不如apache.

所以大并发服务器在响应速度与内存上必须要兼顾，当然还要是响应速度的重点，因为一切都是为了QPS。

如果内存宝贵，可以采用nginx的epoll 方式，事件按顺序执行，并且不建长连接。

如果内存宽裕，可以采用apache方式，伸缩性会好一些。

也许你会问我，为什么不说说CPU的占用情况呢，其实大家要明白一个道理，CPU占用低不一定就是好事，有事情做的时候就得赶紧做，CPU占用当然就高一点，

不占用CPU意味着就不做事，怎么着，事件来了，你还不干了？

QPS达到什么量级才能称做大并发呢？

以日访问量(PV)为2千万来算，即 PV=2*10^7

这样大的访问量,如果用一台服务器来完成（这么大的访问量才用一台服务器，公司肯定扣）

每天80%的工作都是在20%的时间里完成，按照这个理论，服务器集中访问时间 PT=24/4=6小时（中午2小时，傍晚2小时，晚上2小时，正常）

=18000秒，即 PT = 2*10^4

QPS=PV/PT=10^3

才一千就可以达到2千万的量级，不可思议吧。

PV再大点，如腾讯这样的用户级别，PV可能达到100亿,即10^10

QPS=PV/PT=5*10^5

如果采用5台服务器（还是太扣），单台QPS只需要10^5。

你在家里试验时，可能发现10万的QPS是不可能的，但是对于高配的服务器其实不算什么,而如果用50台机子，则QPS则只要1万，家里的PC也能达到吧，嘿嘿。

写到这里，想起曾经到腾讯的一次面试，面试官问我对QQ的服务器并发量及处理技术的一些看法，当时我才毕业一年，懂的也不是很多，还真被吓住 了，从来没考虑过

这样大的并发量，不知从何想起。

其实人普遍都有对大东西的敬畏感，感觉那么大的东西背后一定有高深莫测的技术，但如果这个东西是你做的，你一定不会觉得它有什么

了不起。面试官不过是想让你知道企鹅的技术是一流的，你还差的远。其实P2P聊天技术真的很牛么，只不过腾讯老板抓住了机遇，那个时候如果没有麻花疼，可能还有菊花疼。。。

有机会再专门写写P2P流媒体的体会。