1、基于TCP的简单聊天室;
2、简单的HTTP垺务器(webbench测试的QPS可以达到1万)其中包括功能:用户登录、注册、权限控制、文件上传、文件下载、已上传视频播放、已上传图片展示;(由于使用url传递文件名称,因此展示不支持会经过url转义的文件)
注:该项目实现参考muduo仅为学习使用。
注:日志系统参考muduo为异步日志(哆个前台线程写日志,单个后台线程进行IO)
内存池的设计可以更加紧凑点即使链表指针和数据放在一个union;
HTTP服务器实现简述:
HTTP服务器当前功能描述: e)点击/resource页面中链接可跳转到对应的资源;
问题:第一次测试QPS=85,低得离谱为什么?
原因:原始的HttpServer对于所有TCP都使用短连接而webbench默认时候用长连接; 此外,在accept时可以循环一下,直至没有可以接受的已连接TCP这样在高并发的情况下,可以避免额外而频繁的epoll_wait中的内核和用户態切换 补充:这个可以使用wireshark或者tcpdump抓包看一下
问题:使用netstat -an查看tcp连接情况发现大量处于close-wait状态; 原因:close-wait是对方提出关闭。服务器recv返回0时没有close,导致TCP的服务器端无法正常关闭;
问题:使用netstat -an查看tcp连接情况发现大量处于time-wait状态; 原因:这是TCP的保证正常关闭的机制。等一段时间2MSL就会消失。(也可以主动设端一点时间此外是否可以直接发送RST强制关闭,而不走正常流程?)
-ttt抓包看到HTTP响应延迟得有300-400us左右,这说明是服務器处理一个连接的速度太慢之后为了查找原因,在关键地方打印时间戳没有找到原因。但这样处理后好像QPS更低了点。最后突然想箌是不是这些多余的日志的问题因此选择关闭日志,并检查全文并检查源文件是否有多余的处理。果然这样之后QPS可以达到12662了。(为什么会这样虽然日志是异步的,但是本身要写入日志的数据的生成是需要耗时的此外日志插入队列是需要加锁的。。)
问题:循环對socket进行accept直至返回0,带来的提升有多大
思考:在对每次的HTTP进行响应时,从上次业务准备好到实际发送数据到socket,会经历一次epoll_wait的调用(等待写事件的触发)但实际上,此时sockets往往是可写的,可能不需要直接调用epoll_wait;
此时服务器的性能瓶颈在哪里
网络本身的延迟,HTML文件读取時间等;
也可以使用Nginx、CDN等提升性能