Koa页面上面好像有个问题哦 - CNode技术社区
积分: 1395
谁说我懒，没有签名的
虽然也不是什么大问题 今天突然发现了
应该是HTTP和HTTPS吧
例子展示的是在多个端口监听同一个应用…
列子是没有错但是 同时支持https和https就有点。。。。。。
那个问题是笔误，你看得很仔细啊，我第一次看理所当然的看成http和https了。
linux3.9版本以后的内核，开启SO_REUSEPORT，不同进程可以监听同一个端口。node这样主进程监听，子进程共享fd的做法已经可以绕过去了，惊群问题也就直接交给内核处理了。node对惊群问题是无视，nginx是加锁，这个区别造成了一些人在做压力测试的时候，node看起来比nginx快，其实nginx把accept锁去掉后，性能能提高不少。
我是给服务器加https服务的时候回去看koa的文档 然后就看到了
自豪地采用
我看的是英文文档。。中文的这份不知道是谁维护的吖。。。
我以为是你维护的呢
自豪地采用
同时监听 http https
同时监听多个端口
背后的原因都是一样的。。。
这里主要是想说明 app.callback() 的用法
我不是说用例而是文档上面有点问题 写的是HTTPS和HTTPS了
噢噢，是的诶。下次这类问题，可以考虑提供个 url，因为有不同人翻译了不同版本的文档。
加上了 就是官方的那个中文文档
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于Nginxlua的高性能web.pptx 23页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
你可能关注的文档：
······
··········
基于Nginx/lua的高性能web于连宇议程演示LuaNginx-lua资料演示脚本NginxHello worldRedisMysql与其他HTTP服务连接议程演示LuaNginx-lua资料LualuaJIT语言TableFunctionCoroutineMetatable/metamethod嵌入式Lua执行流程宿主建立lua解释对象宿主提供的api 注入Lua解释器读入lua代码执行编译成二进制则引导执行Lua jit编译成二进制代码location = /lua-version { content_by_lua ' if jit then ngx.say(jit.version) else ngx.say(_VERSION) end ';}tablehaoel = {name=&ChenHao&, age=37, handsome=True}for i=1, #arr do?print(arr[i])endfor k, v in pairs(t) do?print(k, v)end函数闭包function myPower(x)?return function(y) return y^x endend多返回值name, age, bGay = &haoel&, 37, false, &haoel@&进程、线程、协程coroutine协程coroutine 有4个不同的状态： suspended, running, dead, normal co = coroutine.create(function () for i=1, 10 do print(&co:&, i) coroutine.yield() end end)coroutine.resume(co)print(coroutine.status(co))继承metatablelocal mytable = {key2 = &value2&}local ss = {key1 = &value1&};function ss.hello() print(&hello&)endsetmetatable(mytable, {__index = ss})metamethod议程演示LuaNginx-lua资料Nginx-luaNginx进程模型Nginx网络模型Ngx-Lua执行阶段Openresty apiNginx进程模型nginx采用多进程，单Master多WorkerMaster处理外部信号，配置文件以及worker的初始化worker进程采用单线程，非阻塞(epoll)来处理客户端请求和响应Nginx网络模型同步异步阻塞非阻塞Ngx-lua原理Nginx work process共享一个lua vmIO原语直接注入lua vm每个请求开一个coroutine协程，协程数据隔离未就绪、阻塞时，挂起；完成后，还原上下文运行ngx_lua实现Proactor模型 – 业务逻辑以自然逻辑书写 – 自动获得高并发能力 – 不会因I/O阻塞等待而浪费CPU资源Ngx-lua执行阶段set_by_lua / set_by_lua_fileaccess_by_lua / access_by_lua_filerewrite_by_lua / rewrite_by_lua_filecontent_by_lua / content_by_lua_file其他lua_code_ngx.redirect/ngx.exec/ngx.captureAPI调用，取值Nginx的IO操作必须是非阻塞的，如果Nginx在那阻着，则会大大降低Nginx的性能。所以在Lua中必须通过ngx.location.capture发出子请求将这些IO操作委托给Nginx的事件模型CosocketsFile io性能参考资料章亦春:由Lua粘合的Nginx生态环境温铭:Openresty最佳实践叔度:淘宝网Nginx应用、定制与开发实战陈于喆:lua & ngx_lua 的介绍与应用陈皓:Lua简明教程/maijian/article/details/#include &lua.h&#include &lualib.h&#include &lauxlib.h&char *code = &for i=0, 5 do print(\'hello, world!\') end&;int main(){ lua_state *s = luaL_newstate()
正在加载中，请稍后...
84页74页43页54页49页38页52页220页127页81页在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
Nginx把一个request的处理分为多个阶段(phases)。这些阶段会有IO阻塞吗？如果有了阻塞，Nginx会去执行其他requests，但是执行其他requests的时候会有优先级区分吗(会先执行已经进行到后面阶段的requests吗？)？还有，Nginx会在每个阶段都有一个thread pool来处理，还是至始至终就他自己一个thread？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
cat /proc/3776/status|grep Threads 可见Nginx工作进程只有1个线程，其中3776是Nginx工作进程的PID。另外Nginx从1.7.11加入了AIO线程池支持，能够使用AIO多线程读取和发送大文件，以免工人进程被阻塞(小文件用sendfile,大文件用AIO线程池)，要启用线程池支持，configure时需要显式加入--with-threads选项。
转:当listen_fd有新的accept()请求过来,操作系统会唤醒所有子进程,因为这些进程都epoll_wait()同一个listen_fd,操作系统又无从判断由谁来负责accept,索性干脆全部叫醒,但最终只会有一个进程成功accept,其他进程accept失败.所有子进程都是被"吓醒"的,所以称之为Thundering Herd(惊群).
监听套接字在启动时就完成初始化,worker进程通过这些套接字接受,读取请求和输出响应.Nginx并没有像PHP-FPM那样采用master进程来分发请求,这个工作由操作系统内核机制完成,所以可能会导致惊群现象,也就是当listen_fd有新的accept()请求过来,操作系统会唤醒所有子进程.
Nginx解决惊群的思路:避免惊群.具体措施有使用全局互斥锁(accept_mutex on),每个工作进程在epoll_wait()之前先去申请锁,申请到则继续处理,获取不到则等待,并设置了一个负载均衡的算法(当某一个工作进程的任务量达到总设置量的7/8时,则不会再尝试去申请锁)来均衡各个进程的任务量.
Nginx解决惊群的新方法:使用内核提供的Socket ReusePort功能NGINX 1.9.1 支持socket分片:NGINX1.9.1支持socket的SO_REUSEPORT选项,这个选项在许多操作系统的新版本有效,包括DragonFly BSD和Linux(3.9+内核).这个选项允许多个socket监听同一个IP地址和端口的组合.内核负载均衡这些进来的sockets连接,将这些socket有效的分片.当SO_REUSEPORT选项没开启时,连接进来时监听socket默认会通知某个进程.如果accept_mutex off这个指令,此时会唤醒所有的工作进程,它们将为了得到它产生竞争,这就是所谓的惊群现象.如果使用epoll且不用锁(accept_mutex off),当监听端口有读操作时,是会产生惊群现象的.启用SO_REUSEPORT选项后,每个进程都有自己独立的监听socket.内核决定哪个是有效的socket(进程)得到这个连接.这样做降低了延迟并提高了工作进程的性能,它也意味着工作进程在准备处理它们前被赋予了新的连接.
nginx默认以多进程的方式工作,一个master进程和多个worker进程,master进程主要用来管理worker进程.多个worker进程同等竞争来自客户端的请求,一个worker进程可以处理多个请求,但不能处理其它worker进程的请求.每个worker进程里面只有一个主线程,在epoll支持下,采用异步非阻塞的方式来处理请求,从而实现高并发.epoll支持监听多个事件(socket轮询),当事件没准备好时,放到epoll里面,事件准备好了,就去读写.与多线程相比,这种事件处理方式是有很大的优势的,不需要创建线程,每个请求占用的内存也很少,没有上下文切换,事件处理非常的轻量级.并发数再多也不会导致无谓的资源浪费(上下文切换),更多的并发数,只是会占用更多的内存而已.而httpd常用的工作方式是每个请求会独占一个工作线程,当并发数上到几千时，就同时有几千的线程在处理请求了,这对操作系统来说,是个不小的挑战.线程带来的内存占用非常大,线程的上下文切换带来的cpu开销很大,httpd的性能自然就上不去了.Tengine团队之前有对连接数进行过测试,在24G内存的机器上,Nginx处理的并发请求数达到过200万.(平均1G内存可以处理8万多请求)Nginx支持将某一个进程绑定在某一个核上(CPU亲缘性绑定),这样就不会因为进程的切换带来cache的失效,所以推荐设置cpu有几个核就设置几个worker进程.但注意,过多的worker进程,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换,所以worker进程不是越多越好.详细参见:
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。