这次的这个版本相对于前面的第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 socket
import threading
import time
def 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 - 1
s.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万连接还没有挂掉,有意思的很.