@lishuhuakai
2016-11-04T13:15:26.000000Z
字数 1755
阅读 1681
这次的这个版本相对于前面的第6个版本有些许加强,那就是将epoll由LT模式变成了ET模式.
对于采用了
LT工作模式的文件描述符,当epoll_wait检测到其上有事件发生并且将事件通知应用程序后,应用程序可以不立即处理该事件,这样,当应用程序下次调用epoll_wiat时,epoll_wait还会向应用程序通告此事件,直到该事件被处理.而对于采用ET工作模式的文件描述符,当epoll_wait检测到其上有事件发生并且将此事件通知应用程序后,应用程序必须立即处理该事件,因为后续的epoll_wait调用将不会向应用程序通知这一事件,可见,ET模式在很大程度上降低了同一个epoll事件被重复触发的次数,因此效率比LT模式要高.
这个版本和之前的版本最大的一个不同在于accept函数的调用,我这里将main函数的accet函数摘录了出来:
for ( ; ; ) {int connfd = accept(listenfd, &clnaddr, &clnlen);if (connfd == -1) {if ((errno == EAGAIN) || (errno == EWOULDBLOCK)) { /* 将连接已经建立完了 */break;}unix_error("accept error");}handle[connfd].init(connfd); /* 初始化 */addfd(epollfd, connfd, false); /* 加入监听 */}
因为在epoll监听机制中,listenfd已经变成了ET触发,也就是说,一旦有多个连接到来,epoll只会通知我们有连接到了,至于你没有处理,那是你的事情,它不会再通知,只有下一次有连接到来是,它才会通知你,所以一旦有连接到来,我们要一次性处理完已经到来的连接.
代码变化的幅度并不是很大,你可以在这里查看:https://github.com/lishuhuakai/Spweb
下一个版本,我们就要推进到多线程啦,建立一个类似于生产者消费者的模型,主线程往任务队列里不断塞任务,然后工作者进程从任务队列中取出任务来执行.据说这种模式效率会更高,真是迫不及待呢.
这次的代码依旧留存了前一个版本的bug.
为了使得这篇文章有点干货,我在这里教大家如何来测试你的服务器性能.
对于我们这种非常简单的服务器代码而言,python来做一下测试绝对是足够了.当然推荐使用ipython.
我在这里抛一块砖.下面是我的测试代码:
import socketimport threadingimport timedef thread_main():s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.connect(('192.168.44.221', 8080)) # 连接上服务器str = "GET / HTTP/1.1\r\nUser-Agent: Wget/1.12\r\nConnection: close\r\n\r\n"#str = "GET / HTTP/1.1\r\nhi"#print(str)s.send(str.encode())#i = 2#while True:data = s.recv(50000)#print(data)# i = i - 1s.close()if __name__ == '__main__':for i in range(100000):time.sleep(0.001)t = threading.Thread(target=thread_main)t.start()print(i)
上面的代码测试了10万的连接数,你可以用这段代码跑一跑我们之前版本的代码,估计是分分钟挂掉,如何使得服务端产生SIGPIPE消息呢?
非常简单,去掉那条data = s.recv(50000),也就是我们不接收服务端发来的数据,直接关闭掉,我们还可以进行一些奇葩的测试,比如说:
request分做2~3次发送,测试服务器的反应;request,看服务器如何应对;...我在最后发一张我测试的图,爽的不要不要的.
我的最终版本,连续跑了25万连接还没有挂掉,有意思的很.