性能

Qwik.js框架是如何追求极致性能的?!

背景、

Qwik是一款语法"接近"react的前端ssr框架, 前段时间看了两篇Qwik相关的文章, 对这个框架有了些兴趣, 但是去网上搜了一下, 发现相关的中文文章几乎没有了, 所以决定对其好好研究一番, 并且写一篇关于Qwik的特点、基础用法、设计概念, 再加上Qwik对我的一些启发, 接下来就一起看看这款黑科技是何方神圣吧。

一、前提知识:ssr (懂了这里才能看懂Qwik)

从入门学习前端开发开始, 我们不断学习到各种前端的优化方式来提高前端代码的性能, 其中"服务端渲染(ssr)"这种模式帮我们大幅提高了使用前端框架开发的项目的首屏性能, 那么ssr的工作流程是什么样的? 下面我们一起简单梳理一下。…

        

我们是如何利用 Qwik 和 Partytown 削减掉 页面中 99% 的 JavaScript 的

本文为翻译
原文标题:How we cut 99% of our JavaScript with Qwik + Partytown
原文作者:Miško Hevery
原文地址:builder.io/blog/how-we-

Builder.io 兴奋地向大家的宣布,采用 Qwik 之后,我们的主页即使在移动端,其 PageSpeed Insights 跑分也能达到 100/100。

无论你的应用程序有多大,Qwik 都能帮助网页达到这样的性能。我们用 一系列炫酷的技术 得到了这样的分数,这些技术包括:

  • 页面由 Qwik 提供服务,启动(boot)所需的 JavaScript 不到 1kb
  • 我们的主页只会发送 折页上方(Above
        

全新 JavaScript 框架 Qwik:以独特的可恢复性方式提速网页应用

AngularJS 的创造者Misko Hevery近期宣布了新网络框架Qwik测试版本的推出,声称无论应用程序有多大,Qwik 都能够快速地构建。在多数情况下,Qwik 会先下载 1KB 的 JavaScript,在需要的时候才会懒加载或预处理程序和应用程序代码。

在一次名为《如何从主线程中移除99%的JavaScript》的演讲中,Hevery 介绍了 Qwik 背后的原理。

    

vivo 短视频用户访问体验优化实践

本文介绍了 vivo 短视频用户访问体验优化的实践思路,并简单讲解了实践背后的几点原理。

一、背景

我们平时在看抖音快手视频的时候,如果滑动到某个视频画面一直几 s 不动的时候,大概率就会划走了,所以在短视频项目中,画面卡顿是非常影响用户体验的,启播速度越快,就越能留住用户。

启播速度简单来说就是从调用开始播放到首帧上屏的时间,大致可分为两部分:…

        

使用workerman加速任意项目

众所周知,workerman是基于php cli的,由于php cli模式下无法使用php自带的header、sesion、cookie等函数,这导致将传统的php项目无法直接在workerman容器下直接运行。

我一度以为让传统业务在workerman中运行,就必须更改框架甚至业务代码以适配workerman,直到joanhey发了一个issue,打破了我的认知。

他们发布了一个名叫AdapterMan的项目,它可以做到不更改传统框架代码的情况下让你的传统php项目放到workerman中正常运行,并且他们公司已经在生产环境用了2年。

注意,是零代码改动直接让laravel、lumen、Slim等框架的项目在workerman上运行。

目前他们已经在laravel、lumen、Slim、Symfony、CakePHP、Yii2、KumbiaPHP 等做了初步压力测试,性能有很大的提升。

以下是压测结果

Laravel 8

Fw Plaintext Json Single query Multiple query Updates Fortunes
Laravel 14,799 14,770 9,263 3,247 1,452 8,354
Laravel Roadrunner 482 478 474
    

Linux 性能优化

性能优化

性能指标

高并发和响应快对应着性能优化的两个核心指标:吞吐延时

图片

  • 应用负载角度:直接影响了产品终端的用户体验
  • 系统资源角度:资源使用率、饱和度等

性能问题的本质就是系统资源已经到达瓶颈,但请求的处理还不够快,无法支撑更多的请求。 性能分析实际上就是找出应用或系统的瓶颈,设法去避免或缓解它们。

  • 选择指标评估应用程序和系统性能
  • 为应用程序和系统设置性能目标
  • 进行性能基准测试
  • 性能分析定位瓶颈
  • 性能监控和告警

对于不同的性能问题要选取不同的性能分析工具。 下面是常用的Linux Performance Tools以及对应分析的性能问题类型。

图片

到底应该怎么理解“平均负载”

平均负载:单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数。它和我们传统意义上理解的CPU使用率并没有直接关系。

其中不可中断进程是正处于内核态关键流程中的进程(如常见的等待设备的I/O响应)。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

平均负载多少时合理

实际生产环境中将系统的平均负载监控起来,根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时,及时进行分析和调查。 当然也可以当设置阈值(如当平均负载高于CPU数量的70%时)

现实工作中我们会经常混淆平均负载和CPU使用率的概念,其实两者并不完全对等:

  • CPU密集型进程,大量CPU使用会导致平均负载升高,此时两者一致
  • I/O密集型进程,等待I/O也会导致平均负载升高,此时CPU使用率并不一定高
  • 大量等待CPU的进程调度会导致平均负载升高,此时CPU使用率也会比较高

平均负载高时可能是CPU密集型进程导致,也可能是I/O繁忙导致。具体分析时可以结合mpstat/pidstat工具辅助分析负载来源

CPU

CPU上下文切换(上)

CPU上下文切换,就是把前一个任务的CPU上下文(CPU寄存器和PC)保存起来,然后加载新任务的上下文到这些寄存器和程序计数器,最后再跳转到程序计数器所指的位置,运行新任务。其中,保存下来的上下文会存储在系统内核中,待任务重新调度执行时再加载,保证原来的任务状态不受影响。

按照任务类型,CPU上下文切换分为:

        

缓存您的 CORS,以提高性能和利润

CORS 是许多 API 所必需的,但基本配置会产生大量额外请求,从而减慢每个浏览器 API 客户端的速度,并向您的后端发送不必要的流量。

这可能是传统 API 的问题,但在无服务器平台上会成为一个更大的问题,在无服务器平台上,您的账单通常直接与收到的请求数量挂钩,因此这很容易使您的 API 成本翻倍。

所有这些都是不必要的:它正在发生,因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。

        

为什么您的网页大小应小于 14KB

也可以在dev.to上阅读(警告它远大于 14kB)

拥有一个较小的网站可以使其加载速度更快——这并不奇怪。

令人惊讶的是,一个14kB页面的加载速度比一个15kB页面快得多——也许更快——而一个页面和一个页面612ms之间的区别是微不足道的。15kB16kB

这是因为TCP 慢启动算法。本文将介绍它是什么,它是如何工作的,以及为什么你应该关心。但首先我们将快速回顾一些基础知识。

    

延迟加载非关键 CSS

CSS 文件是渲染阻塞资源:它们必须在浏览器渲染页面之前加载和处理。包含不必要的大样式的网页需要更长的渲染时间。

在本指南中,您将了解如何以优化关键渲染路径和改善 First Contentful Paint (FCP) 为目标来延迟加载非关键 CSS。

以次优方式加载 CSS #

以下示例包含一个带有三个隐藏文本段落的可折叠项,每个文本段落都使用不同的类来设置样式:…

        

推迟 CSS 和 JavaScript 资源以提高页面加载速度的现代方法

为了提高页面加载速度,您可以通过仅调整页面的 HTML 代码来延迟 CSS 和 JavaScript 资源。

  1. 延迟 CSS
  2. 延迟媒体
  3. 延迟 JavaScript

CSS、字体和 JavaScript 等资源被视为渲染阻塞。这意味着浏览器在实际呈现页面内容之前需要时间来加载它们。

所以这些资源的文件越大,加载它们的时间就越长,用户看到页面内容的时间就越长。

要检查页面加载速度和渲染阻止资源,您可以直接在浏览器 (Chrome) 中使用Lighthouse工具。这是衡量 Web 性能的重要工具之一。

为了防止渲染阻塞资源减慢您的页面速度,您可以实施下面列出的小 HTML 更改来解决此问题。

延迟 CSS

处理 CSS 负载的正确方法是将样式拆分为关键 CSS 和非关键 CSS。

  • 关键- 这些样式是显示即时内容所必需的,一旦页面加载(首