第十二讲- 高性能服务器设计.ppt

网络化编程 第十二讲 高性能网络服务器 程序设计 高性能的服务器系统 高性能硬件系统 CPU、内存 I/O：磁盘、网卡 高效的软件系统 应用程序 OS 协议 高速的网络 服务器设计模型 多进程模型 进程池 Prefork 多线程模型 线程池 prethread 单进程事件驱动（SPED）模型 内核线程服务器 混合模型 N进程 * SPED N进程 * m线程 非对称多进程事件驱动 AMPED 多进程模型 进程fork开销巨大，花费时间长 进程池模型 Prefork足够多的进程，形成一个“池子” 限制进程数目 可以动态调整进程数目 进程池模型 进程关系 父进程只派生子进程 父进程参与服务—— 父子同等 父进程只接收连接，accept() 后交给子进程 进程池模型 见代码 server/serv02.c 先fork N个子进程 每个子进程独立的accept 和 服务 “惊群” (Thundering herd) 现象 多进程的开销 (0) 测试 fork + 调度 开销 多进程的开销 (1) fork() 的速度究竟有多快？ scheduling 多进程的开销 (2) 内存消耗 Copy-on-write机制 多线程模型 线程的开销比进程小 有些OS下，创建线程也很慢. 人们提出了thread pools的方法. 有些OS下，一个进程的线程数目有限制 线程的同步与互斥代码复杂 单进程事件驱动模型 没有进程/线程调度开销 内存开销小 采用多路复用 + 非阻塞方式工作 内核服务器 Linux中采用内核线程 khttpd TUX (Threaded linUX webserver) by Ingo Molnar et al. For 2.4 kernel. 减少了系统调用的上下文切换开销 编程困难，容易出错 典型的Web事务 传统WEB服务器 IO密集 —— 既有网络IO，也有磁盘IO 电子商务网站 计算密集——动态网页 + 加密运算开销很大 多进程/进程池模型 Apache：一个进程处理一个连接 进程池：预先准备好进程，降低因为fork带来的开销 多线程模型 单进程事件驱动模型 SPED Zeus, thttpd, lighttpd, …… 但 Disk I/O 是阻塞的 stat, open, read, readir, sendfile 等都是阻塞的 单进程的Disk IO效率低 异步Disk IO？ AMPED模型 和 Helper进程 Flash服务器：Princeton大学的研究项目 主进程做事件驱动处理 使用helper进程来处理阻塞的Disk IO 阻塞点：stat, open, read, readdir, … 内核的高速I/O机制 网络服务器通常是IO密集型的，而不是计算密集型的 内核的高速I/O机制对高性能的服务器非常重要 网络服务器的大量时间花在内核中和频繁的系统调用上， 高效的系统调用接口非常关键 Socket readiness通知机制 传统的select()机制 FD_SETSIZE 限制 传统的poll()机制 /dev/poll Realtime Signals + SIGIO kqueue epoll Select/poll 的效率 用户进程和内核之间需要传递两次描述符列表；内存拷贝的代价大； 内核将所有活动的描述符都标识出来，但用户进程还需要逐个测试描述符是否活动；重复工作！ 内核也不高效： 大列表需要申请内存，拷贝，扫描 ; 如果没有活动的，就需要逐个更新描述符的“钩子”； 进程被唤醒，还需要查找是哪个描述符唤醒了进程； 进程也需要逐个查找：三次扫描。 /dev/poll 最早由Sun 提出（Solaris）. 打开一个设备 /dev/poll, 将”描述符集” 写入到/dev/poll中. 采用 ioctl 来等待事件. ioctl 返回多少事件, 然后你从/dev/poll读取这么多描述符出来. /dev/poll只给你准备好的描述符集. 用户程序不需要遍历描述符集来查找可用的描述符. Linux下没有很好的实现. /dev/epoll (1) Linux 2.4 的补丁，一个名为 /dev/epoll 的虚拟设备. 将 pollfd 写入到设备中，或者将pollfd从设备中清除 /dev/epoll (2) 添加一个描述符 Write /dev/epoll (3) 删除一个描述符 /dev/epoll (4) struct pollfd *pfds; struct evpoll evp; for (;;) { ? evp.ep_timeout = TIMEOUT; ? evp.ep_resoff = 0; ? nfds = ioctl(kdpfd, EP_POL