引用:肥猫布里奇高 发表于 2023-04-08 15:42 已修订,感谢课代表 |
捉虫: 原文:“实现方式4:epoll既然逐个排查所有文件句柄状态效率不高,很自然的,如果调用返回的时候只给应用提供发生了状态变化(很可能是数据 ready)的文件句柄,进行排查的效率不就高多了么” 实际应该是:“实现方式4:poll”吧,这是在总结前面 poll 的缺点 |
引用:一剑开天 发表于 2022-09-07 17:24 |
引用:JackJiang 发表于 2022-09-07 14:28 终于明白了IO多路复用要解决哪个场景下的问题、问题是什么、解决问题的几种方法、以及各个方法实现的大致思路。感谢站长! 以下是我读完后对IO多路复用的理解。 linux 下,一个网络连接对应一个 socket,一个 socket 对应一个文件描述。服务端程序要做的就是将每个文件描述内的数据读到 buffer 中,然后把 buffer 数据处理完成后响应给客户端。如果有一万个并发连接,就意味着服务端应用程序会创建一万个文件描述,然而并非每个文件描述中都是有数据的,没有数据就意味着该文件描述不可读,进程处理该文件描述时就会阻塞。 如果每个文件描述中数据的读取都直接交给进程,那么进程就需要对这些文件描述逐个判断,看它是否可读,若不可读,则进程阻塞在此,这样处理的效率会非常低下,这就是同步阻塞—— BIO 的实现。 后来出现了一种同步非阻塞——NIO,select 的实现是先将这些文件描述(数量上限 1024 个)复制到内核并对它们的状态进行监控,一旦有文件描述的状态变为可读写,则 select 函数返回并唤醒进程。进程被唤醒后遍历所有的文件描述,不可读写则跳过,可读写则执行读写。这种实现 在连接数非常多时,效果并不乐观。 NIO——poll 的实现仅仅消除了 1024 这个文件描述符的数量上限。 NIO——epoll 在监控的同时,将那些可读写的文件描述记录了下来,随后唤醒进程,并将记录好的文件描述提供给进程,这样进程就无需全部遍历一次,可以直接对记录中的文件描述执行读写,效率较高,使用最为广泛。 当所有文件描述都不可读写时,无论使用 sellect、poll 还是 epoll,进程依然处于阻塞状态,所以它们都属于同步 IO。 |
引用:一剑开天 发表于 2022-09-07 12:54 把这篇读一下试试《从根上理解高性能、高并发(三):深入操作系统,彻底理解I/O多路复用》 |
IO多路复用那里还是看不明白,我是不是应该先把《unix网络编程》读完呢? |
学习了 |
还不错 |
引用:lordran 发表于 2021-11-02 14:07 读的很仔细,已勘误,感谢! |
"维持1亿用户在线需要10万台服务器",这里应该是1万台吧? |
怎么都这么厉害 |
引用:boylong08 发表于 2020-11-22 11:48 一个个都是这么牛 |
引用:linlisnotlwl 发表于 2020-05-01 21:58 根据《unix网络编程》描述,epoll在等待数据阶段是非阻塞的,但是在数据从内核空间复制到用户空间时是阻塞的 |
引用:linlisnotlwl 发表于 2020-05-01 21:58 看怎么理解了,epol 的回调的确是非阻塞的,只在读取信息的时候同步。 |
6、C10K问题的本质 原文“处理的方式都是requests per second,并发10K和100的区别关键在于CPU。” 实际应该是 “处理的方式都是requests per thread,并发10K和100的区别关键在于CPU。” |
“epoll技术的编程模型就是异步非阻塞回调,也可以叫做Reactor”,有些疑问,epoll不是同步的吗,异步IO模型不是Proactor吗 |
之前还觉得epoll多神秘,看完这个发展历程,突然就觉得epoll也就那么回事,感谢站长的分享,太赞了 |
引用:xuyaomin 发表于 2019-05-21 11:39 肯定能 |
条理很清晰,继续看下去,肯定能学到不少知识,赞 |
赞一个,长知识了 |