有个项目要求支持10万并发， 考虑用nginx， 因为淘宝团队号称nginx可以相应200万并发在24G内存的机器上，于是跃跃欲试，但是在本地vmware-ubuntu虚拟机上和云主机，仅测试简单的index.html with 'It works'采用ab测试工具，最高才3万并发不到，从网络上优化了/etc/sysctl.conf 也没有多大改善3. nginx如何承担10万并发， 是否需要重新编译内核，还是有其他优化参数可以在ubuntu 或者centos上设置。首先。淘宝的实验是nginx维持2M HTTP长连接不断，无需返回数据，需要开发一个nginx module，而不是你理解的每秒接入2M个HTTP短连接的同时还要回传静态文件！前者有一台牛X服务器和调整内核TCP参数就搞定了，后者得用服务器集群才能完成。文章链接：http://ehealth-aussie.blogspot.com/2012/11/tuning-and-optimization-of-nginx-for-2.html和http://www.itzk.com/thread-583354-52-1.shtml其次。要考虑ab本身的性能问题，因为TCP有流控，ab性能不行，也会拖累nginx回包和关闭链接的延迟，最终就影响整体并发，尝试同时开多个ab发包。最后。改进方向可以从网络中断处理入手。并附上我PC虚拟机测试结果（fedora 20, 四核2.3GHz, 2GB内存）统计access.log看总请求数，能稳定在每秒28K：网络中断处理，一个worker，两个ab，不过中断处理占用大量系统CPU而且只压一个core，也试了更多的worker或ab，性能甚至会下降。
当前单worker的性能接近极限了，strace统计下上述过程系统调用延时，虽然attach后进程整体效率下降很大，但系统调用的统计还是比较准确：理顺上面的表格逻辑，可能还要单独strace一次nginx worker的处理流程。总之一次请求处理仅系统调用占用接近30us，加上少量用户CPU和进程上下文切换，每秒处理极限就在30k左右。vmstat查看，系统CPU时间占绝对多数，系统（网络）中断和上下文切换比较高，在虚拟机下也很难改善了。“总之一次请求处理仅系统调用占用接近30us，加上少量用户CPU和进程上下文切换，每秒处理极限就在30k左右。” ----终于等到高手回复了，至少解释了单机多核配置再好，也总是ab 压不出3万以上接近10万的并发结果。对于楼主提到用多个ab 客户端压测，这个我也试过了，结果是在没压死的情况下，各个ab 客户端压测结果总和 还是未能超过30K 甚至更多。看来是nginx server 端 短连接并发的极限就是你提到的30us， 30K并发。的确，如果用nginx 维护长连接，可以轻松超过30K， 或许可以达到10万，但是不知道长连接怎么压测呢？最近写了一个异步IO的工具，正好测试长连接的情况，2G内存CentOS 6.5 x86-64下，10万长连接无压力。文章链接：http://blog.chinaunix.net/uid-190176-id-4234854.html拜读一下博客里的测试文章，写的很详细，如果不是钻牛角尖式的，用AB 测试10万短连接 高并发，就忽略了实际应用中长连接的，多客户端在线的高并发。而且长连接的确是nginx的优势所在。我大概看了一下实际应用中提到的并发需求， 先引新浪微博的几个峰值介绍：
http://tech.sina.com.cn/i/2012-01-30/15386667286.shtml
新浪科技讯 北京时间1月30日下午消息，据《时代周刊》报道，在龙年新春零点微博抢发活动中，新浪微博发博量峰值再创新高，龙年正月初一0点0分0秒，共有32312条微博同时发布，超过Twitter此前创下的每秒25088条的最高纪录。新浪微博注册用户已经超过2.5亿，每天有接近1亿条的微博内容产生。
http://net.chinabyte.com/110/12513110.shtml
新浪科技讯，新浪(Nasdaq:SINA)微博发博量峰值再创新高。2013年第一分钟，新浪微博的发布量高达729571条，相较龙年春节大幅提升51.6%。其实也想拿点儿 淘宝 和12306的数据，时间关系没找到具体的。我想表达的是，nginx 的应对高并发请求的性能已经没有问题了，之所以会有上百台，上千台乃至上万台服务器再为看上去业务并发不是很高的东西，我的意思是新浪微博还没有报告说每秒钟发出10万条微博，连twiiter 也还没有这个记录。因为发一条微博所承载的请求是成倍的，而且这些请求并不全是简单快捷的“helloworld”测试请求，这里面包含了静态请求，尤其是耗流量的图片请求，也包含了消耗服务器cpu的数据请求，而且由于集群的引入，还会有数据同步的问题，并保证业务数据的完整性一致性，为了保证这些，一个看似简单的读请求 或者 写请求 将会触发一系列集群内部的，甚至各个集群之间的，即时或者间隔的请求。至此，我觉得可以为我发起的这篇帖子作个小结了，能应对高并发请求的服务器技术如nginx ，搭建配置都不复杂，复杂的是能应对高并发业务的服务器架构，当然像google这样的基本上解决了服务器集群架构问题的机构，着眼点已经转到如何在保证高并发业务需求的同时，降低服务器架构的成本，低碳环保，不重复建设。才有了公有云的服务平台。但是我不敢说云解决了一切问题，举个例子，如果业务逻辑是残疾的，不可以拆分的，无法通过扩展服务器架构来升级，比如添加新的节点，或更换硬盘，cpu，内存等等，那么什么服务器架构也帮不了你。因为不可扩展的业务逻辑，最终将变为吸纳资源的黑洞。举个简单到有点儿脑残的例子， 业务处理里意外触发了一个占用大量资源，网络或者数据库连接，或者cpu计算的死循环，而且进程本身设置成了忽略用户断开连接，忽略运行时间限制， 那么最终后果将会是，进来一个连接挂住一台服务器，即便你有几千台服务器，很快就会挂住所有集群。上面的例子基本上不会发生，只是一个比较极端的例子。线上集群的健康状况，一般会有层层监控，线上运行的代码一般会有层层的代码审查。除非集群被注入了高级的病毒程序，否则不会出现这么极端的后果，当然集群的防火墙，还有集群中有很多自家开发的系统，以及层层设置，都在避免被入侵。行，希望关注这篇帖子的同学，不要继续纠结于Ab 测试nginx的 短连接的高并发了，也无需太纠结于现有服务器技术的高并发，还是把精力用到业务逻辑分拆，可扩展上来吧，这才是王道。注：本文版权属chinaunix社区所有，如有转载请注明出处。
作为国内数据库与大数据领域最大规模的技术盛宴，2016第七届中国数据库技术大会(DTCC)将于2016年5月12日-14日召开。大会云集了国内外顶尖专家，共同探讨MySQL、智能数据平台、数据治理、大数据创业、大数据深度学习等领域的前瞻性热点话题与技术，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。3月16日前，订购DTCC大会门票即享7.8折优惠！团购更有折上折！
原文作者：；如有侵权，请联系管理员删除。
