我觉得服务器在成为大并发前,首先要能承受住大并发的压力,无论能否正常返回,首先不能崩溃。
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流媒体的体会。