cf v0.6 发布 - 增加gzip支持与协议解析性能优化

cf v0.6 发布了，主要改进包括：

feature

• httpc与httpd库增加的gzip头部支持, 用于优化网络与数据传输效率.

• httpd库增加注册中文(utf8)路由支持, 用于特殊一些场景.

• httpc库增加basic与jwt方法, 用于构造常用的头部.

update

• 优化对底层库增加预分配机制, 提升效率与可读性.

• 优化大部分网络协议的解析效率, 提升解析效率.

• httpd库取消默认超时限制, 如果有需要可以自行调用相关接口增加.

• 更新了大部分cloud库内相关API, 有兴趣自行查看不再单独介绍.

fixed

• 修复qiniu库的认证bug.

• 修复class与logging的引用问题.

• 修复admin库的cookie异常与admin.view的一些问题.

• 修复httpd库上传文件.

• 修复了一些错别字.

关于gzip支持

当Web App需要返回大数据集的时候, 这通常不是一个很好的设计. 这在服务端渲染模板的情况下很常见, 框架的设计无法弥补这一缺陷的.

我们知道任何一个模板文件都能轻易达到>1K的程度, 更有同时还会包含更多一些业务数据. 这种情况通常无法避免, 我们只能思考更好的解决方案.

之前有开发者提出过对gzip的支持. 但是当时框架正处于功能开发阶段, 无法分出心来对特性、优化、性能进行定制开发. 好在现在这个阶段已经度过.

目前已经对httpd与httpc库增加了gzip的compress与uncompress支持. 在某些测试代码中已经证明, 传输字节的消耗至少减少了50%-80%.

在httpd库中我们提供了httpd:enable_gzip方法. 在客户端支持压缩的情况下, 我们会对相关路由的返回值进行压缩. 开发者无需关心数据格式.

在httpc中是会增加Accept-Encoding: gzip头部请求压缩. 这在用户与开发者角度是不会感知的, 通常内部已经自动识别完成转换.

关于httpd的socket请求超时限制

从大部分测试中发现, http客户端都已经支持Connection: keep-alive. 框架默认增加连接超时机制对开发者来说不够友好.

相信大部分Web开发者都会为Web App框架提供的负载均衡器, 同时负载均衡器会对大部分后端Web App提供的socket连接提供连接池机制.

大部分负载均衡器都能完成连接超时功能, 所以框架的超时机制反而对连接池的建立与回收有稳定性上的隐患. 并且隐患通常开发者很难知晓与排查.

而Web框架运行在一个对连接复用性需求比较高的场景下, 所以将默认设置为无超时限制. 这样能让框架隐藏在负载均衡器后的时候运行的更加稳定.

当然! 如果开发者对此有异议, 并且不希望cfadmin运行在负载均衡器后面并且要提供超时机制. 从当前版本开始, 只需要在启动的时候设置超时时间即可.

关于 Unix Domain Socket

众所周知! 市面上绝大部分Web开发框架都提供了unix sock机制. 但是对其应用场景与实际效果却了解甚少. 这是因为一些开发者很少接触到服务器部署.

我们通常只可能部署一台负载均衡器与后端多个Web App应用程序进行通信达到负载均衡的目的. 但是这也许满足不了一些特殊的开发者, 他们的环境有特殊的要求.

当负载均衡算法已经不是问题的时候, 减少内部连接消耗与效率则变成了我们关注的重点. 有限的连接池与端口范围成为制约我们的瓶颈. 我们需要更好的解决办法.

Unix Domain Socket 是一种进程间通讯机制, 它在工作起来更像是Pipe与SocketPair. 比起基于internet的socket连接有有更少的消耗.

Unix Domain Socket 两端通信没有端口的概念, 因此也就没有端口范围的限制. 通常您只会在某些代理、负载均衡器中看到它的应用. 例如: Nginx.

我们完全可以假设单台服务器硬件配置足够高的情况下, 运行N个Web App实例进程. 让负载均衡器通过Unix Domain Socket与其进行通信.

例如: 在一个16核心64G内存的服务器上启动10个cfadmin进程. 通过让负载均衡器占用4~6核心与10~20G内存来维护上万的连接是轻而易举的.

每个cfadmin进程对CPU与内存的利用率都非常高. 当其他Web框架需要占用G单位大小的内存时, cfadmin可能只需要1/10的内存.

有理由预计当每个cfadmin需要占用4G以上内存的时候, 您可能才需要考虑单台服务器设计是否需要进行横向扩展.

关于底层数组与哈希表预分配机制

Pre-allocation仅在Lua语言中有效, 并且这也是一种针对性的优化. 我们在大部分场景中测试到一些数据结构的操作会进行rehash与resize.

Pre-allocation的目的是减少频繁resize/rehash的问题, 让基础数据结构运行的更加平滑, 最大程度利用数据结构缓存. 这在框架内部使用很频繁.

同时考虑到了开发者对一些对象的调整与扩展优化了数据初始化的大小. 所以在对象建立(例如: Websocket)的时候, 也会预先分配一定的基础内存.

而底层基础内存结构在使用完毕后, 会被框架清理后进入缓存列表内. 等待下一次使用时候复用即可. 这也是为什么框架无需定制内存分配器也能工作的很好.

就上述调整与优化, 我们在实际测试中提高了5%-10%的效率.