|  | 
 
| 分为本地、线上测试,所有框架均用默认配置 
 本地测试环境: MacOS 12.7
 测试样本 并发数300 持续10秒 每个框架执行3次,取平均值
 测试命令 bombardier -c 300 -d 10s http://127.0.0.1:3000/
 
 本地helloworld(删除多余的代码,只响应返回helloworld文本)
 
 自己写的框架
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec     80010.09    4575.56   89098.13
 Latency        3.82ms   372.66us    43.54ms
 HTTP codes:
 1xx - 0, 2xx - 795573, 3xx - 0, 4xx - 0, 5xx - 0
 others - 0
 Throughput:    17.16MB/s
 
 
 next.js框架
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      3755.82     515.57    5050.54
 Latency       89.26ms   734.71ms     16.04s
 HTTP codes:
 1xx - 0, 2xx - 37618, 3xx - 0, 4xx - 0, 5xx - 0
 others - 275
 Errors:
 dial tcp 127.0.0.1:3002: connect: connection reset by peer - 158
 the server closed connection before returning the first response byte. Make sure the server returns 'Connection: close' response header before closing the connection - 74
 timeout - 42
 write tcp 127.0.0.1:57438->127.0.0.1:3002: write: broken pipe - 1
 Throughput:     8.97MB/s
 
 
 nuxt.js框架
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      2181.77    1577.13    5278.16
 Latency      158.78ms      1.11s     16.24s
 HTTP codes:
 1xx - 0, 2xx - 21373, 3xx - 0, 4xx - 0, 5xx - 0
 others - 322
 Errors:
 dial tcp 127.0.0.1:3001: connect: connection reset by peer - 195
 the server closed connection before returning the first response byte. Make sure the server returns 'Connection: close' response header before closing the connection - 95
 timeout - 29
 write tcp 127.0.0.1:53730->127.0.0.1:3001: write: broken pipe - 1
 write tcp 127.0.0.1:53728->127.0.0.1:3001: write: broken pipe - 1
 write tcp 127.0.0.1:54196->127.0.0.1:3001: write: broken pipe - 1
 Throughput:     1.46MB/s
 
 --------------------------
 --------------------------
 本地真实网站,需要读取数据库,构建页面
 
 自己写的框架
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      1082.09    1980.78   10934.21
 Latency      271.90ms    27.26ms   465.08ms
 HTTP codes:
 1xx - 0, 2xx - 11111, 3xx - 0, 4xx - 0, 5xx - 0
 others - 0
 Throughput:    15.63MB/s
 
 
 next.js
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec       849.89     377.48    4222.65
 Latency      889.52ms      3.79s     30.91s
 HTTP codes:
 1xx - 0, 2xx - 8524, 3xx - 0, 4xx - 0, 5xx - 0
 others - 274
 Errors:
 dial tcp 127.0.0.1:45454: connect: operation timed out - 129
 the server closed connection before returning the first response byte. Make sure the server returns 'Connection: close' response header before closing the connection - 109
 dial tcp 127.0.0.1:45454: connect: connection reset by peer - 30
 timeout - 5
 write tcp 127.0.0.1:53003->127.0.0.1:45454: write: broken pipe - 1
 Throughput:     7.05MB/s
 
 以前用nuxt.js写的网站换了新的数据库,所以不测试
 
 --------------------------
 --------------------------
 线上测试环境: CPU 1H(i9-11900K)1G的美国小鸡
 线上测试helloworld
 
 自己写的框架 cpu占用率最高4% 平均3.2%
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      1142.57    2227.97   15024.57
 Latency      256.43ms    60.41ms   557.79ms
 HTTP codes:
 1xx - 0, 2xx - 11666, 3xx - 0, 4xx - 0, 5xx - 0
 others - 0
 Throughput:   260.31KB/s
 
 
 next.js框架 cpu占用率最高48%,平均35%
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      1098.43     857.13   10456.58
 Latency      269.57ms   124.37ms      2.47s
 HTTP codes:
 1xx - 0, 2xx - 11268, 3xx - 0, 4xx - 0, 5xx - 0
 others - 0
 Throughput:     4.15MB/s
 
 
 nuxt.js框架 cpu占用率最高76%,平均68%
 ==============>
 Statistics        Avg      Stdev        Max
 Reqs/sec      1097.11     852.92    8386.19
 Latency      269.70ms    83.80ms      0.86s
 HTTP codes:
 1xx - 0, 2xx - 11250, 3xx - 0, 4xx - 0, 5xx - 0
 others - 0
 Throughput:     1.20MB/s
 
 
 --------
 ----------------
 ----------------------
 
 线上测试的请求性能接近(1.1w,这是cpu的瓶颈),不过cpu占用率差异很大。
 
 以前用nuxt.js、next.js来开发一个网站。
 后来一些原因想仿写一个:
 1. 网站运行期间莫名错误不知道哪来
 2. 页面加载会有很多额外文件,臃肿
 3. 页面上有nuxt或next的文字,不舒服
 4. 类名太长,没有压缩
 5. 构建时间太久
 6. 对于简单网站大材小用了
 
 于是写了一个简单的ssr框架,模仿了nuxt和next的文件目录结构,很好处理了上面的问题,相当于就是字符串拼接
 性能高的原因是bun这个js运行时,内置web服务器是uwebsockets,性能非常的高。在techempower网站中js语言排名最高
 不过bun发展没有很久,避免不了一些bug,遇到一个比较严重bug,挺不可思议,当使用Bun.listen返回大于130kb的数据,pc端能够正常接受,但是移动端就卡住,无响应。但是使用Bun.serve就没有这个问题。
 当时反馈过,然后怀疑我有隐藏的换行符,我还没来得及解释就关闭了
 
 关于原因第四点,我没测试之前认为类名压缩了能很好降低文件体积,诸如.main-left-content-a => .a 、.video-content-div => .b
 不过还是想多了,顶多降低1~2kb大小,没我预期的多,看来gzip压缩比我想象中要牛逼
 不过类名压缩能够隐藏原有类名的含义,还是有点保护性的
 | 
 |