Flare|Flare 制作记录(应用前后端性能优化)

两周前,在给颜值在线的 flame 提交了几个 PR 之后,我将它封装成了容器,用于书签和在线应用的管理。
但是在迁移个人书签的过程中,我发觉 flame 在性能上的表现并不是特别好,于是我做了一个改良版:flare
写在前面 在聊 flare 之前,我想先聊聊 flame。
flame 是一个颜值在线的导航页项目,你可以将你常用的书签和在线应用存储在它上面。它由一个波兰小哥创建,项目地址是 https://github.com/pawelmalak/flame
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

在试用之后,我觉得项目还不错,于是稍作调整,封装了一个新的镜像:https://github.com/soulteary/docker-flame
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

在项目文档中,记录了我的修改:

  • 简化程序功能和依赖(如K8S),减少软件包体积,重构了一些细节逻辑,简化应用启动流程。
  • 重写了天气获取逻辑,使用城市名称替换经纬度来获取天气数据。
  • 对程序已有的一些小 BUG 进行了修复,支持中文搜索。
  • 对程序进行了简单的汉化。
但是随着深入使用,我发现页面有着比较大的性能问题。
因为波兰小哥采用了 SPA 方案,项目内又包含了 6700 多个 SVG 图标、以及若干网页字体,并且在接口上有一些小问题,导致了页面体积非常大,接口请求数量也非常多。
甚至当你上传一些包含元素比较多的 SVG 作为你书签图标的时候,由 React 触发的页面渲染会造成浏览器卡死。
我大概有几百个书签需要处理,预估未来书签数量还会增长,所以我使用程序批量创建了接近一千个书签。然后我发现渲染如此多的书签,页面会出现卡顿,甚至在页面内搜索包含关键词的书签也会感受到明显的掉帧。
所以,我决定重新写一个轻量一些的程序,来解决我的需求。新的项目地址在这里,如果你好奇的话,可以试试看:https://github.com/soulteary/docker-flare
制作 flare 的过程,其实也是 flame 性能调优的过程。不过在解决问题之前,我们首先得能定位问题有哪些。
应用性能问题分析 关于这个应用的性能优化,其实并不复杂,和传统应用优化差别不大:优先减少计算量,在实在减少不了的情况下使用计算效率更高的方式来解决问题。
不过结合使用场景来说,在分析技术问题之前,可以先从功能入手。
对于我不适用的功能
首先从功能上看,我不需要这个应用与 Docker 集成,提供“服务发现”功能。比如在我启动容器后,这个应用会自动将新启动的容器作为书签或者应用进行添加。
其次,在拥有自己的 SSO 服务之后,我也不再需要使用简单的账号密码登录之类的功能,所以这个功能也可以去掉。
最后,关于书签数据的存储,我觉得在缺少用户体验非常棒的 Web 编辑器的前提下,可能不如配置声明的方式更易于管理和维护。(你可以使用任何你喜欢的编辑器来更新和维护内容,你可以使用 Git 或者任何你喜欢的方式,以白盒形式保存你自己的数据)。
基于上面的变化,我大概可以少写几个部分的代码:容器(Docker & K8S)集成、登录鉴权、应用和书签,以及书签分类的 “CRUD”。
前端架构中的问题
Flame 项目中,作者使用都是 create-react-app 脚手架创建的项目,项目依赖为: React v17 + TypeScript + Redux,为了提供简洁一致的图标,作者在前端引入了 Templarian/MaterialDesign-JS,一个被精心处理过的 DOM 结构非常简单的 SVG 图标库。
在使用构建工具打包、服务端 GZip 压缩之后,需要传输接近 1MB 的资源,原始脚本程序体积接近 3MB。相对膨大的程序体积导致了页面加载和执行时间都会比较长。比如页面页面首次渲染时间在 1s 上下浮动,多数情况下会超过 1s,完成时间一般都在 1.5s 以上。可能是作者对于服务端程序开发不够熟悉,虽然在前端进行应用配置更新时会复用接口,但是在内容页面展示时,会调用多达8个接口。此外,为了在页面中展示和更新天气信息,波兰小哥还使用了 WebSocket 来进行数据交互。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

其他的问题,在文章前面已经提到过了,就不赘述了。
后端架构中的问题
【Flare|Flare 制作记录(应用前后端性能优化)】项目使用的技术栈为 Node.js,Web 框架为市占率非常高的 Express 的最新版本,ORM 框架选择的则是 Sequelize,数据存储落地为 SQLite3 。上面的选择粗看问题不大,如果应用不需要公开提供浏览访问,应该不会出现任何性能问题。
但是,如果我们仔细观察服务响应,会发现有一些请求的响应的时间非常长,比如页面资源、比如对于页面至关重要的 JS 程序资源,它们的获取都消耗了接近 400ms。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

此外,前端发起了多次请求来获取数据,结合数据存储使用 SQLite,如果提供公开内容访问,很容易遇到性能瓶颈。
针对应用进行改进 当我们清楚了解到上面的问题之后,比如容易采取的方案是:基于原程序进行重构调整,简化前端请求、合理拆分模块、处理资源加载和执行时机,调整数据存储和处理方式,提高服务端响应能力等组合拳。然而,这会是最简单和收益最高的方案嘛?
调整前端实现
如果说在需要交互的页面程序中使用 MVVM 框架会有较高的收益和性价比,那么在缺少多端组件代码复用、没有服务端渲染需求的场景下,使用这类框架则是一个性价比不高的选择。
或许有同学会问,如果不使用 React、Vue、Angular 这类框架,难道在 2022 年还要再拾起 jQuery 等老的工具吗?虽然可以,但其实在近乎于纯展示的场景下,我们可以脱离 JS 来实现业务功能和简单的交互,比如自动获取焦点、菜单按钮的激活状态变化、甚至是带有动画效果的天气图标。
所以,在调整实现的时候,其实还有一个选择:不使用任何脚本。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

在完成程序之后,我们可以看到从服务器获取整个页面数据、结构解析、样式计算、元素布局、页面绘制的完整时间在 33ms(包含了 idle 等待时间),其中关键流程的时间消耗加起来不到 10ms,而完成页面渲染的时间更是缩短到了 1.65ms。
在得到了页面快速渲染能力之后,即使不使用浏览器针对资源进行缓存,加速渲染,我们也能够做到页面切换的“无刷新”浏览(因为渲染速度足够快)。
调整后端实现
虽然我非常喜欢使用 Node.js,以往也分享过不少基于 Node.js 编写的程序或者优化实践,但是,为了能够低成本提高高性能的资源响应,这里进行技术栈切换是必要的:比如 Golang。
在使用 Golang 简化程序功能后,程序对于每个请求的响应基本能够保持在几毫秒的水平(受限于网络传输),相比较之前大概下降了2~3个量级。页面关键的 DOM ContentLoad 时间更是缩短到原来的八分之一。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

结合上面的前端优化提到的渲染时间来粗略估计,从资源下载到渲染加起来都不到 10ms,如果不是浏览器的一些限制,绘制帧率应该能够远超 60 帧,进一步满足我们实现“即使刷新了也比没一些没刷新的实现还顺滑”。
上面的实现中,我将页面图标请求和页面文档进行了拆分,在书签数量和图标种类不多的场景下,或许并不是最优的方案,但是一旦书签数量级到几百、上千之后,你会发现图标拆分可以极大地提升性能。
当然,为了满足数量比较少的场景,我也对合并输出进行了实现,算上网站 favicon 获取,一共只有两个请求。在书签不是很多的时候,渲染性能甚至比文档和资源拆分输出效率更好。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

图标资源优化
Flame 使用的方案是读取后端接口配置,从前端脚本中动态创建 SVG 图标并插入文档中,Flare 程序默认的方式则是将 SVG 和文档拆分,以应对大量书签状况下的页面性能问题。
虽然解决了页面性能问题,但是服务端 IO 问题却会伴随而来,所以这里还需要处理资源在服务端的释放和读取问题,尽量将资源的磁盘 IO 变为零。
听起来比较玄乎,但其实结合代码生成的方式,还是蛮好实现的。当然,因为 Go 存在自动 GC,所以在不同的资源被使用的时候,会出现大量内存的分配,影响效率,这里可以考虑使用持久化方案来解决问题,处理起来挺有意思的,受限于篇幅和主题就不展开啦。有一部分我在前两篇文章中提到了,关于 Golang 嵌入资源的使用和优化。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

比如,在不针对 HTTP 服务实现做任何优化、限制运行资源为两核心的前提下,仅优化资源 IO 后,能达到稳定 3ms 输出资源,每秒提供2万7千次以上的响应服务。
容器镜像的优化
除了常规优化之外,容器时代的应用,镜像优化也是非常关键的。容器优化方式,我在前面的文章反复提过多次,所以也不再展开了,感兴趣可以自行翻阅之前的内容。
# docker images | grep fla soulteary/flare0.1.122b18ad73c6612MB soulteary/flaume2.2.0b39fffc0ca81152MB pawelmalak/flame2.2.0fa47c93c0af6179MB pawelmalak/flame2.0.0729b0fcea7f0190MB

可以看到,相比较原版程序,优化后的程序在本地解压后的尺寸大概是之前十五到十六分之一。
额外的优化 如果我们使用 lighthouse 针对 Flame 前端实现进行测试,能够看到前端程序在实现上的一些小问题,得分虽然四个环绿三个,但是只有一个环是绿色的。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

在重新实现的过程中,除了简化结构,调试实现之外,还顺手将这四个圈都打到了满分(Chrome 版本 v97+)。
Flare|Flare 制作记录(应用前后端性能优化)
文章图片

最后 聊到这里,相信你已经了解了我是怎么做的啦,如果你对 Flare 感兴趣,并且也需要一个简单的导航程序,可以访问项目 https://github.com/soulteary/docker-flare,来亲自上手试试。
--EOF
我们有一个小小的折腾群,里面聚集了几百位喜欢折腾的小伙伴。
在不发广告的情况下,我们在里面会一起聊聊软硬件、HomeLab、编程上的一些问题,也会在群里不定期的分享一些技术沙龙的资料。
喜欢折腾的小伙伴欢迎扫码添加好友。(添加好友,请备注实名,注明来源和目的,否则不会通过审核)
关于折腾群入群的那些事
如果你觉得内容还算实用,欢迎点赞分享给你的朋友,在此谢过。
如果你想更快的看到后续内容的更新,请不吝“点赞”或“转发分享”,这些免费的鼓励将会影响后续有关内容的更新速度。
本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议,欢迎转载、或重新修改使用,但需要注明来源。 署名 4.0 国际 (CC BY 4.0)
本文作者: 苏洋
创建时间: 2022年01月19日
统计字数: 5054字
阅读时间: 11分钟阅读
本文链接: https://soulteary.com/2022/01...

    推荐阅读