Linux网络服务器性能比较研究.docVIP

Linux网络服务器性能比较研究 　　摘要：　高性能网络服务程序在当前的linux环境下应用非常广泛，不论是主流web服务器，还是mmo服务器，都需要高性能的网络服务器结构提供支撑。就主流的linux网络服务器模型性能进行比较，得出一般性结论，为以后网络开发人员对网络服务器的选择提供一定的参考依据。 　　关键词：　linux；服务器；性能；比较 　　1　标准tcp客户端的设计 　　在客户端主程序中需要的一般参数包括服务器端ip地址，服务器端口，客户端fork形成的子进程数，子进程向服务器发送的请求连接数量以及要求服务器返回的数据字节数。据此给出客户端的基本模型： 　　for　（i　=　0；　i　bind--listen--[accept--read--write--close]--close其中括号内为服务器循环。 　　2）为一个请求分配一个进程或是线程，主线程调用阻塞在accept处，每个新的连接请求到来，都实时为其生成线程处理其请求。但多数情况进程的线程数有限，创建线程的开销和过多线程后进行上下文切换的开销，对于真正的系统的设计，该模型只具有理论上的实用性，后面的实验也验证这点。 　　3）服务器端预派生一定数量进程或线程，让所有线程都阻塞在accept调用的地方。以前的观点认为大量进程或线程同时阻塞在accept处时，会产生“惊群”现象，即所有的线程或进程都被同时激活，但只有一个获取连接描述符并返回，其它线程或进程又转为睡眠。linux从2.2.9及以后的版本都不存在这个问题，只有一个会被激活。 　　4）Tcp预先派生进程服务程序，accept使用文件上锁或者线程上锁保护模型。一般线程锁一次只有一个线程可以阻塞在accept处。避免所有预产生的线程都直接阻塞在accept，可以避免惊群问题。而文件锁不具有通用性，将不参与模型性能比较。 　　5）主线程处理accept，预派生多个线程（线程池）处理连接。主线程在accept返回以后，将clientfd放入线程的消息队列，线程池将读取线程消息队列然后处理clientfd。这里主线程只对accept进行操作，快速返回后继续调用accept，有效的避免了拒绝连接的问题，当加大线程消息队列的长度时，可以显著减少消息队列处的系统调用频繁度。 　　3　六种服???器模型的测试比较 　　3.1　实验结果 　　客户端进程数　用户时间（耗费在用户进程上的cpu时间（s））系统时间（内核在系统调用花费的时间（s））服务器发送字节数　每个进程处理连接数为 　　1）迭代服务器 　　2）tcp并发服务器，每个客户一个子进程 　　3）tcp预先派生子进程，accept无上锁保护（最后一项为预派子进程数） 　　（相比tcp并发服务器，处理时间缩短两至三倍，但预派子进程越多，性能有所下降） 　　4）tcp并发服务器，每个客户一个线程 　　可见性能稍优于进程并发 　　5）tcp预先派生线程池，每个线程各自accept 　　性能优于为每个客户创建一个线程 ，当预派线程变多时性能明显下降 　　6）tcp预先创建线程池，主线程统一accept 　　该模型性能稍逊于模型五，主要是该模型既需要互斥锁又需要条件变量。 　　3.2　一般性结论 　　1）纵向比较 　　①　对于迭代服务器：客户进程数与系统处理时间成线性关系，处理相同的连接数，采用多进程的方式发送可以缩短30%～40%的时间。当连接数与进程数相同时，对于返回字节数多的链接，系统花费的时间会多一些，但不会根本上改变系统性能，服务器发送数据占系统处理时间的一小部分。 　　②　对于tcp并发服务器：虽然局部范围内连接数与系统处理时间的关系具有波动性，但总体仍然可以得出以下结论，对于总数相同的的连接，增大客户进程数可以缩短系统处理时间。 　　③　对于tcp预先派生子进程：当预派子进程数相同，客户进程数增大时，每个链接的平均系统处理时间会增加少许。对于当预派子进程数不同时，派生进程少的服务器可以明显降低系统处理时间，也就是说，预派子进程变多时，会增加系统负担，降低系统平均处理效率。 　　④　对于每个客户一个线程的tcp并发服务器：当总连接数相同，客户连接进程变多时，每次连接的平均时间会有一定增加。 　　⑤　tcp预先派生线程池，每个线程各自调用accept：当派生的线程数下降时，系统性能会有一定提高；相同的连接数，客户端进程变多时，每个连接的处理时间增加。 　　⑥　tcp预先创建线程池，主线程统一accept：每个客户进程发送的连接数相同，进程变多时，单个连接处理时间增加；连接总数相同，客户进程变多时，处理时间增加。 　　2）横向比较 　　平均时间比较：这里处理每个连接平均时间最短的是迭代服务器，这个结果是好