终于忍受不了windows的独断专行,封闭滞后,用过ubuntu之后将工作学习的重点全部转向了linux,几个月下来感觉还不错。
三年来我一直在致力于建造一个简单高效的web服务器,先后用.net
java尝试,结果发现基本的静态文件处理方面都太不如人意,在项目几近封闭的时候放弃了,因为做web已经6-7年了,所以有了一些总结,先是寄希望
于.net的一套合理架构解决我的大部分问题,避免重复劳动,后来发现问题多多,先是想效率不行,然后时常有一些莫名的错误,IIS也经常出错误,所以所
有的上层构建都显得没有意义,也就渐渐是去了信心,后来才下定决心自己作一套web服务器,ruby
ror创始人说得好,“可能有一万种方安是和你,但是我们之给你最适合的哪一种”,我计划中的业务模式必须要能满足快速、运行高效、SEO支持度好、分布
式、快速扩展等多种大中型网站的要求,简单来说就是能够快速将Idea变成成熟稳定的web产品,cms就不用说了,只是各种底层之上的玩具,不具有实际
的大规模应用价值,这也是为什么在云云web服务器中还要自己作一套出来的原因。
在后来转向了java,花了大量时间阅读tomcat、resion、jsp等架构于模式,自己构建出来一套简化的能运行java程序(类似于
servlet)web服务器,理念是将所有的业务构建在xml+xlt之上,对应的不支持的浏览器和搜索引擎采取在服务端执行然后发送的模式,以求达到
速度和SEO的要求,xml由后台控制器产生,可以自定义数据库,采取双备份模式,对于需要认证的页面不产生静态xml,然后还构建了自己的AJAX库,
所有需要SEO支持的页面均采用后台合成,已经有了一定的自动化程度,如果在此基础上继续下去就可以构建类似于cms的应用程序了,这个时候发现整个服务
器的负载是在是不怎么样,那时java还不支持nio的net
service,即使支持,介于java本身的复杂度也不可能构建出类似于Nginx的web服务器,那么上面所有的架构旧都是去了意义,那么只能将接近
一年的成果再次搁浅。当然,并不能说浪费了一年的时间,毕竟对于web的内部架构,传统的jsp
Asp.net的构够有了深刻的理解,还在中文分词、网络蜘蛛等有了相当的深入,这都得意于java
后来发现了nginx,传奇似的一个web服务器,内存控制相当稳定,运行的也很平稳,速度也很快,超过apache,与lighttpd基本持平,才发
现web服务器是要用c来写的,本来打算借用或者更改模块,但发现阅读别人的代码总是那么困难(可能是本人比较笨),基本的编辑环境都很难构建起来,所以
还是打算从头自己来,一劳永逸,“不要重复造轮子”在这里应该是不适用的,多少年来中国很少有自己的能站的住脚的技术那出来,nginx还是人家俄罗斯
的,ruby也是人家日本的,好的程序不一定都要出自于美国,再说我想要得不是一套专业的商业web服务器,而是一项最适合我业务的定制的web服务器,
正是因为多次尝试更改其他web服务器(tomcat、resoin等实现的异常复杂,每个请求需要10几个类的继承、处理、装发才能到达servlet
执行)的失败与痛苦,才让我更加坚定信心,其实每个web服务器核心只有很少的一块代码,但是他们总是把他层层包装,因为他们需要应对所有的业务模式。
现在我走向了c。
重新拾起c当然是很痛苦的,尤其对于我这种已经习惯了面向对象的语言的人来说,但还是坚持下来了,首先我就很务实,先实现了hashtable、
memory
pool,动态array,string等常用功能,一来让自己对c有个熟悉深入的过程,二来有利于将编程习惯多少统一到面相对想的习惯,然后就是web
server。
首先我同样是借助于windows的IOCP,同样问题多多,也没有多少业务是构建在其上的,痛苦万分之际遇到了ubuntu,解决了我的基本驱动问题,
让我有能力在全linux环境下工作,也同样让我能够是用epoll进行构架,netbeans c还是不错的编辑器的,虽然相对于visual
studio的高度智能远远不及,但是能在linux上有这么个工具已经算是万幸了(6.1才推出c的支持),不过现在最大的问题是对于多线程的调试难了
很多,mem poll等也都是得意于当时在windows下已经用vs调试好了,如果在linux下调试的华就麻烦大了。
现在静态部分已经基本成型,项目源代码不过40个文件,控制200K以内,算是超轻量级的了,局域网环境下测试性能还稍微领先于nginx,大幅领先于apche,ab的结果如下:
100用户并发10000次,环境ubuntu8.04,奔四3.0,1G内存:我的server(3个读线程3个写线程处理静态请求,本测试在单核机器上没有充分发挥):
Requests per second: 6906.85 [#/sec] (mean)
Time per request: 14.478 [ms] (mean)
Time per request: 0.145 [ms] (mean, across all concurrent requests)
Transfer rate: 867.50 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 1.3 6 14
Processing: 4 7 1.6 7 22
Waiting: 0 4 1.9 5 21
Total: 11 13 2.0 13 29
Percentage of the requests served within a certain time (ms)
50% 13
66% 14
75% 14
80% 15
90% 16
95% 18
98% 20
99% 20
100% 29 (longest request)
Nging 0.53
Requests per second: 5784.46 [#/sec] (mean)
Time per request: 17.288 [ms] (mean)
Time per request: 0.173 [ms] (mean, across all concurrent requests)
Transfer rate: 1451.32 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 2.6 3 13
Processing: 2 13 4.8 13 34
Waiting: 2 11 4.6 11 33
Total: 8 16 3.8 16 34
Percentage of the requests served within a certain time (ms)
50% 16
66% 17
75% 18
80% 19
90% 22
95% 25
98% 28
99% 29
100% 34 (longest request)
lighttpd/1.4.19
Requests per second: 5948.69 [#/sec] (mean)
Time per request: 16.810 [ms] (mean)
Time per request: 0.168 [ms] (mean, across all concurrent requests)
Transfer rate: 1611.50 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 4 2.7 4 19
Processing: 2 12 5.3 11 43
Waiting: 0 9 4.8 9 37
Total: 6 16 5.6 15 46
Percentage of the requests served within a certain time (ms)
50% 15
66% 17
75% 19
80% 20
90% 23
95% 27
98% 32
99% 36
100% 46 (longest request)
Apache/2.2.8
Requests per second: 3403.92 [#/sec] (mean)
Time per request: 29.378 [ms] (mean)
Time per request: 0.294 [ms] (mean, across all concurrent requests)
Transfer rate: 987.14 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 6.0 4 28
Processing: 4 22 9.9 22 74
Waiting: 2 19 8.7 19 71
Total: 10 28 8.8 27 74
Percentage of the requests served within a certain time (ms)
50% 27
66% 31
75% 34
80% 35
90% 40
95% 45
98% 52
99% 59
100% 74 (longest request)
综合来看,apche是4个中最差的,我的webserver高出他100%还多,nginx和lighttpd都还是不错的,到这一步我仿佛看到了希
望,辛辛苦苦两年多的积累,终于有了一个小的突破,可以让我放心地在此架构上不断完善,使其更加稳定,然后就可以构建上层应用服务
道路还很漫长,随着模块的不断完善只要最终的webserver性能下降不至低于nginx就心满意足了,能够完全掌握起运行状态才是我想要得,以后我会
用更多的文章对于websever的各个部分进行更为严格的测试,包括内存池等基础构建的健壮性都需要时间的考验,但是走过来才发现很多事情做起来比现想象的容易。
这篇文章是我从我baidu博客上转过来的,那里的专业人士比较少,当然这点成绩不足以在这里卖弄。这是几个月前的结果,现在很多部分已经出来了,包括持久连接支持,反向代理等功能,经过进一步优化,现在性能反而有所提升。
做过游戏服务器的人可能觉得http server是很简单的,但是真正作起来了才发现不是这样的,最大的不同在于http的客户端不是固定的,请求是多样的,不受服务器端控制的,网络是及其不稳定的,所以容错性就要高,这恰恰是c的软肋,所以在实现诸如持久连接的过程中就于到了很多麻烦,大家可以在我以后的博客中看到,已经写了大量文章,如有失误之出望多多指教,至于是否开源我觉得不重要,Nginx等大量优秀架构的代码都是开源的,不用心我们照样看不懂,也许等这个服务器出具模型就会开源给大家了,别的优点没有,中文注释还是写得挺全的,有利于国人阅读,附属的一些代码会在下面的博客中先陆续载出来,望大家多多支持。
分享到:
相关推荐
胜得:致力于成为中国一流PCB制造商.pdf
海外化工系列研究:泛能拓(VNTR)经营情况跟踪:致力于推进业务改善计划和钛白粉价值稳定计划.pdf
安凯:致力于多媒体应用处理器芯片设计.pdf
扬帆迪东:致力于打造电动汽车新品牌.pdf
深度学习:致力于发展学生高阶思维.pdf
意法半导体:致力于MEMS的应用多元化.pdf
北京汇发宠物中心:致力于犬芯片标识的植入推广犬.pdf
中艺:致力于半导体自动化生产设备的设计、研发和制造.pdf
Tomcat是稳固的独立的Web服务器与Servlet Container,不过,其Web服务器的功能则不如许多更健全的Web服务器完整,如Apache Web服务器(举例来说,Tomcat没有大量的选择性模块)。不过,Tomcat是自由的开源软件,而且...
回购致力于我们的Web技术类的项目2。 启动应用程序 后端 您必须初始化每个微服务,然后为所有微服务启动线程。 在终端上: cd Back/ yarn nodemon Nodemon是一个观察者,可确保正在运行的代码是最新的! 前端 ...
webappI-labs:致力于都灵理工大学Web应用I课程实验室开发的存储库
致力于提供稳定、可扩展、定制化的客户服务一站式平台 准备工作 分配应用:登录后台->客服管理->渠道管理->添加Web 开发文档 说明 kefu文件夹中是 在线客服演示,方便开发者自定义访客端UI, im文件夹中是 im演示,...
subterfuge_web:致力于Subterfuge棋盘游戏开发的博客
这是一个Web Server的时代,apache2与nginx共舞,在追求极致性能的路上,没有...功能定位上,与经常充当最前端反向代理的nginx不同,caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性,使用配置
WebBuilder是一款跨平台、...完善的基础架构,具有大型应用系统必须的完整功能,使应用系统的开发仅需致力于业务的开发。 您可以到 http://www.putdb.com 在线使用或下载到本地使用,软件开源并基于GPL协议授权。
港股公司研究-安信国际证券-和誉B02256.HK点评:致力于开发创新型小分子肿瘤疗法的临床阶段生物制药公司.pdf
OpenResty 致力于将你的服务器端应用完全运行于 Nginx 服务器中,充分利用 Nginx 的事件模型来进行非阻塞 I/O 通信。不仅仅是和 HTTP 客户端间的网络通信是非阻塞的,与MySQL、PostgreSQL、Memcached、以及 Redis ...
20210506-中信建投-水滴-WDH.US-水滴Waterdrop商业模式及招股书关键信息梳理:致力于保险和医疗保健服务的领先技术平台.pdf
致力于高效计算的站点。 建造 安装 安装 第一次只有步骤: npm ci 然后构建站点: hugo --cleanDestinationDir 该站点位于./public文件夹中。 释放 构建步骤的输出可以托管在任何静态站点托管程序上。 SFF.life...
Progressive Web App(PWA)是由谷歌提出的一整套技术解决方案,它致力于为 Web 提供出色的用户体验,并完美体现了渐进增强原则。作为为数不多的实战入门用书,《PWA 实战:面向下一代的Progressive Web App》旨在...