这次的这个版本相对于前面的第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,看服务器如何应对;
• 总是不关闭连接,看能不能将服务器拖垮;
• ...

我在最后发一张我测试的图,爽的不要不要的.

这里写图片描述