# 1、背景
上次发了文章[我用 GPT4 写了个开源项目](https://mp.weixin.qq.com/s?__biz=Mzg3ODk3MTk0Nw==&mid=2247483828&idx=1&sn=fc110500aa211539174b51459cb19892&chksm=cf0adcf0f87d55e6fb0230df2f16cf30b2538c66e24447878578728e0fc2721ca14c33f6e114#rd)  
主要功能是实现了，但代码不够紧凑。  
使用过程比较繁琐，需要手动上传jmx，再执行jmx，最后再生成报告。  
想增加一个新功能，把这三个步骤合并成一个步骤，但发现重复代码还蛮多的。    
这当然是不能忍的，那就把这个任务交给ChatGPT（GPT4模型）吧



# 2、GPT4重构
## 2.1 代码抽取
话不多说，直接把代码扔给ChatGPT

![image.png](https://img.huacai.one/huacai-blog/24e75b0c4c471f478e009ab0c6ac3da2.image.webp)
 
 看看效果，有模有样的？
 
![image.png](https://img.huacai.one/huacai-blog/5e130818d754cd4047a29f3ec6fc11bd.image.webp)
   
  但是它偷懒了！！！  
  并没有实现上传jmx和生成报告的接口
  
![image.png](https://img.huacai.one/huacai-blog/a75bd000b7ced062ad7c2f0d2d0b4732.image.webp)

嗯，看不错哦。代码都移动好了

不过还有个小问题，JMeterManager做了一个全局实例化，然后在路由中使用它的实例

使用全局变量这种方式不够优雅，那要怎么改呢
## 2.2 使用依赖注入
![image.png](https://img.huacai.one/huacai-blog/f0b5c723f52f00aca4d421d913cb810e.image.webp)

真不错啊，即使我的提问有问题，还能给我想要的答案！


## 2.3 全局变量和依赖注入比较
那么问题来了，全局变量和依赖注入，除了优雅，还有啥区别

看看FastAPI之父Ayo的说法，你觉得呢
![image.png](https://img.huacai.one/huacai-blog/7aee089ed64267b60296480ea34174e8.image.webp)


# 3、实现新功能
第一版的时候，三个步骤才能完成压测：
- 调用upload_jmx先上传jmx
- 然后调用execute_jmx执行，得到jtl
- 在通过generate_html_report_by_jtl_file接口得到最终的HTML报告

新功能是把三这个步骤合成一个，看看ChatGPT给出的答案
![image.png](https://img.huacai.one/huacai-blog/6ceb366594442dbc22e7652899bb499c.image.webp)

整体上没毛病，返回的结果是有点问题的  
自己手动改一下就OK

看看最终效果，nice！  
上传完直接执行，并且生成报告

![jmx-upload-execute-report](https://img.huacai.one/jmx-upload-execute-report.gif)

# 4、FastAPI挂载静态
## 4.1 需求分析
当然，实际情况没有那么顺风顺水。下面是踩坑之路    
Jmeter生成的HMTL报告，是一个文件夹
目录长这样
```shell
$ tree reports -L 2
reports
├── http-bin-json-2023-04-29_10-21-30
│   ├── content
│   ├── index.html
│   ├── sbadmin2-1.0.7
│   └── statistics.json
├── http-bin-json-2023-05-04_21-36-21
│   ├── content
│   ├── index.html
│   ├── sbadmin2-1.0.7
│   └── statistics.json
├── http-bin-json-2023-05-04_21-59-39
│   ├── content
│   ├── index.html
│   ├── sbadmin2-1.0.7
│   └── statistics.json
├── http-bin-json-2023-05-04_23-17-37
```
reports是所有报告的根目录，它下面的每个子目录都是一份完整的报告
例如http-bin-json-2023-04-29_10-21-30这个文件夹，就是指http-bin-json.jmx这个文件在2023-04-29_10-21-30这个时间执行的报告
前端访问的方式是
`http://localhost:18000/view_report/http-bin-json-2023-05-05_07-17-10/`
也就是说，只需要传入文件夹名称即可  

那么这个功能怎么实现，看ChatGPT怎说
![image.png](https://img.huacai.one/huacai-blog/8d73ade243a0cf9ce2beb9a0b541e982.image.webp)

## 4.2 移除Jinja2
这显然不OK，访问静态文件为啥要增加Jinja2模板，重来

![image.png](https://img.huacai.one/huacai-blog/7bd49a3bc6cc4e50c3f8768745495150.image.webp)

厉害啊，还考虑到内存泄漏和实际的使用场景
但是不符合我的要求，我希望是传入文件夹，就直接渲染页面了，它返回了一个路径，接下来就是一顿乱操作了  
## 4.3 踩坑
![image.png](https://img.huacai.one/huacai-blog/357452a3907829a6fb8760ad4071493a.image.webp)

![image.png](https://img.huacai.one/huacai-blog/bcd6276b27f50b15a35f0619e6c1df31.image.webp)

## 4.4 解决
后面有点多，就不一一列举
其实解决方法很简单
```py
app.mount("/view_report", StaticFiles(directory="reports", html=True), name="reports")
```  
只需要这一句就行了，把静态文件挂载，就能直接访问。  

# 5、总结
为什么后面会发生这么多问题，首先我是FastAPI的新手，很多东西不了解。  
其次，在调试的时候，没有注意浏览器缓存的问题，即使改成代码正确的了，但因为缓存，看到缺失错误的结果。

我用GPT4重构了项目

# 1、背景
某天在群里讨论在测试平台上集成压测的方案



![image.png](https://img.huacai.one/huacai-blog/d5023f340df68650a8f1466ff4a89005.image.webp)

我就突发奇想，要不在我的接口平台也加上执行Jmeter的功能？

# 2、流程图

说干就干，先稍微捋一下流程图

![image.png](https://img.huacai.one/huacai-blog/9349c9081afa233fd912346174774fcf.image.webp)

![image.png](https://img.huacai.one/huacai-blog/54f53d16e5decfa19a4ff12638ce2a2d.image.webp)

整体上没啥问题，还是那句老话，先完成再完美
能跑通了再说
# 3、设计分析
## 3.1整体分析
通过流程图，可以分出来，需要至少这些功能：
- 用户上传jmx文件
- 用户执行jmx
- 查看报告

把这些再细化一下，直接交给ChatGPT

![设计分析-Django.png](https://img.huacai.one/huacai-blog/6f26d79712b081e1419b515b41b3c1ce.%C3%A8%C2%AE%C2%BE%C3%A8%C2%AE%C2%A1%C3%A5%C2%88%C2%86%C3%A6%C2%9E%C2%90-Django.webp)

可以看到，ChatGPT给出来的答案并不能满足需求，我还没验证具体功能，至少一看就知道少了执行jmx的接口

## 3.2 执行jmx
接着问ChatGPT

![追问执行jmx.png](https://img.huacai.one/huacai-blog/97ef28947fe683eed2cfc224745a44d5.%C3%A8%C2%BF%C2%BD%C3%A9%C2%97%C2%AE%C3%A6%C2%89%C2%A7%C3%A8%C2%A1%C2%8Cjmx.webp)

## 3.3 修复Dockerfile
执行接口看着没问题了，Dockerfile似乎有问题，缺少了Java环境

![缺少Java环境.png](https://img.huacai.one/huacai-blog/190aa06d49adac26a4514e69a9e2fb18.%C3%A7%C2%BC%C2%BA%C3%A5%C2%B0%C2%91Java%C3%A7%C2%8E%C2%AF%C3%A5%C2%A2%C2%83.webp)

## 3.4 切换成FastAPI
很好，似乎都OK了？
好像Django创建项目还是有点啰嗦，换成FastAPI试试？

![换成FastAPI.png](https://img.huacai.one/huacai-blog/9f4e8cc39750d77a173aab6e7910c2fe.%C3%A6%C2%8D%C2%A2%C3%A6%C2%88%C2%90FastAPI.webp)

# 4、调试
一切就绪，开始调试
- [x] **jmx文件上传** OK
- [ ] 执行jmx文件 不OK

报错了
![](https://img.huacai.one/huacai-blog/de3a6f2e0b59b355f3ed6c86723e53f5.æ¥éäº.webp)

这里ChatGPT瞎说的，后面自己看日志排查，是容器里面Jmeter都没有安装好
Dockerfile里面给出来的5.4.1版本是没有的，直接换成5.5版本就OK啦

查看报告呢？
截图没有了，因为ChatGPT Plus账号过期，现在连历史会话都加载不出来，号都直接废了

# 5、发布
ChatGPT已经把核心的功能都写得差不多了，我再做亿点点的修改，就能把项目发布啦  
初版的源码
> https://github.com/lihuacai168/Jmeter-Toolkit/releases/tag/V0.1.0

最新源码
> 呜呜呜，对你有帮助的话，记得点赞哦  
> https://github.com/lihuacai168/Jmeter-Toolkit

# 6、总结
- ChatGPT（GPT4模型）真的很强，整体理解能力，联系上下文都完全没问题
- 输入的prompt越详细，得到的效果越好
- prompt大概需要包括几个点，已知条件，问题描述，期望输出的格式
- ChatGPT有时候会一本正经的胡说八道，需要使用者有一定的识别能力

我用GPT4写了个开源项目

# 1、标题党嫌疑

首先，我要承认在前一篇文章中，[前端性能优化 (提升 13 倍)](https://mp.weixin.qq.com/s?__biz=Mzg3ODk3MTk0Nw==&mid=2247483770&idx=1&sn=8f8f96fc0e10e7343a2498db77d6a0c0&chksm=cf0adc3ef87d5528d4c8019f8a940f206f525f6175154e4f4f4fabca193d1c30e76d5114d074#rd)  
我的标题确实有点标题党的嫌疑。虽然我在实际操作中发现了一些明显的性能提升，但对于大家关心的加载速度来说，提升并不是特别显著。这里，我向大家道歉。




# 2、JS瘦身效果

虽然JS瘦身0.4MB对加载速度影响不大，但它确实在打包速度上有了明显提升，这对开发者来说是一个好消息。同时，我想强调的是，资源包替换也算是一种性能优化的手段。虽然效果可能没有预期的那么明显，但它确实帮助我们在某种程度上优化了性能。

# 3、按需导入与全局导入

在前一篇文章中，我提到遇到了一些问题，没有实现按需导入，而选择了全局导入。现在，在经过专业前端大佬的指导后，我已经解决了这个问题，并成功实现了按需导入。
## 3.1 局部导入
将全局导入改为局部导入后，打包后的JS从18MB降低到了17MB，但实际浏览器传输数值并没有变化，仍为1.1MB。  
![image-20230428222312626](https://img.huacai.one/image-20230428222312626.webp)
![image-20230428230457350](https://img.huacai.one/image-20230428230457350.webp)

## 3.2
但一个更大的收获是，我发现并注释掉了一个未使用的组件（echarts），使得JS从17MB降低到了12MB，浏览器网络传输也降低到了806KB。 从一开始的1.5M，经过两轮操作后，降低700KB，算是小一半的体积了，效果还算蛮不错？  
![image-20230428225756590](https://img.huacai.one/image-20230428225756590.webp)
![image-20230428231151199](https://img.huacai.one/image-20230428231151199.webp)

# 4、CDN的应用

关于CDN，实际上我已经在项目中进行了应用。
## 4.1 使用CloudFlare CDN
> https://fast.huacai.one/fastrunner/login  
> test
> test2020

<img src="https://img.huacai.one/image-20230429090554363.webp" alt="image-20230429090554363" style="zoom:50%;" />  

测了好几遍，都是强制刷新，没缓存。速度不够稳定，有时候400多ms，有时候1s多，有时候5s。    
毕竟是免费，还是海外节点，将就用着吧  

## 4.2 腾讯云直连对比
> http://119.91.147.215/fastrunner/login  
> test
> test2020


<img src="https://img.huacai.one/image-20230429091431055.webp" alt="image-20230429091431055" style="zoom:50%;" />
<img src="https://img.huacai.one/image-20230429091535147.webp" alt="image-20230429091535147" style="zoom:50%;" />
第二张首页加载很快，但是不知道两张小图片加载那么慢，不理解啊。虽然不影响使用，但还是有那么点不爽

# 5、总结

再次感谢大家的反馈与指导。这次的优化尝试让我收获了很多，也让我更加深入地认识到性能优化的重要性。我会继续努力，寻找更多的性能优化手段，为大家带来更好的用户体验。同时，我也希望大家能够多多指教，让我们共同进步。

再聊前端优化,性能小幅提升?

# 1、背景
有好几个童鞋跟我反馈，你测试平台在线demo加载好慢啊

慢确实是慢，但这事情不能赖我呀，肯定是腾讯云的锅。  

腾讯云8m带宽的服务器，可是我斥巨资购入的呀



<img src="https://img.huacai.one/image-20230426203251930.webp" alt="image-20230426203251930" style="zoom: 50%;" />

<img src="https://img.huacai.one/image-20230426203746466.webp" alt="image-20230426203746466" style="zoom:50%;" />

这可是价值5040元的服务器啊！（虽然实付只是198😝）

<img src="https://img.huacai.one/image-20230426204038997.webp" alt="image-20230426204038997" style="zoom:50%;" />

好家伙，续费的时候，加了这个峰值带宽是啥意思？那我现在的带宽是不是8M？我还真测了一下

![image-20230426205126674](https://img.huacai.one/image-20230426205126674.webp)

腾讯云大佬如果看到了，别打我，我不是黑腾讯云，只是想引起你们的注意（万一把我招进去了呢）

算了，算了。这个锅还是我自己来背

# 2、为什么慢？
打开Chrome开发者工具，一看（chuck-xxx.js忽略，是我自己安装Chrome插件的js）

![image-20230426205613332](https://img.huacai.one/image-20230426205613332.webp)

vendor.xxxx.js是啥，为啥这么大？

问一下ChatGPT

![image-20230426205956156](https://img.huacai.one/image-20230426205956156.webp)

哦，原来是第三方依赖啊，那到底依赖了啥

通过`webpack-bundle-analyzer`分析，可以看到`monaco-editor`这个模块占大头，超过1/3了!

然而在项目中，只有一个地方用到，这太不合理，要干掉！

![image-20230426193205800](https://img.huacai.one/image-20230426193205800.webp)

# 3、优化方案

`monaco-editor`很强，很优秀（你是个好人，但我们不合适）

既然`monaco-editor`很大，但编辑器还是得有，那用啥来代替呢？

那还是继续问一下ChatGPT

![image-20230426210639860](https://img.huacai.one/image-20230426210639860.webp)

## 3.1 CodeMirror方案

CodeMirror这个是比较出名的，在虾皮的时候，看前端同学也是用了这个。

那就先用这个是试试。

哦豁，这东西默认安装是vue3版本，然而当前项目是vue2

降低版本到适配vue2的版本

结果问题又来，这玩意默认高度是300px，真的坑，初始化的配置还不能直接设置高度

一顿操作后，菜鸡如我，并没有解决这个问题，暂时放弃

![image-20230426211206152](https://img.huacai.one/image-20230426211206152.webp)

## 3.2 Ace方案

所幸CodeMirror翻车后，还有plan B，那就Ace，看ChatGPT的回答，应该更加符合这次的需求

那就选它了！

用Ace替换掉Monaco之后

看看webpack-bundle-analyzer，app.js从15.82MB降低到了10.19MB，降低5.63MB

前面看到的Monaco是6.1MB，算下来Ace就是0.47MB，Monaco是Ace的12.98倍（标题有了）！

![image-20230426193131143](https://img.huacai.one/image-20230426193131143.webp)

# 4、收益

## 4.1 打包容量

打包整体的容量减少了14M！

![image-20230426213311695](https://img.huacai.one/image-20230426213311695.webp)

## 4.2 打包速度

打包时间缩短约36s，相当可观呀！

![image-20230426213527039](https://img.huacai.one/image-20230426213527039.webp)

## 4.3 首页加载容量

减少了0.4MB，看着不算很大？不行，我就想吹一下

![image-20230426214019478](https://img.huacai.one/image-20230426214019478.webp)

## 4.4 首页加载速度

可以通过下面两个地址实测

[CloudFlare CDN访问](https://fast.huacai.one/fastrunner/login)

[腾讯云访问](http://119.91.147.215/fastrunner/login)

账号密码
test
test2020



# 5、总结

引用一句Facebook(现在Meta)著名的口号和价值观

"Done is better than perfect"（完成比完美更好)

目前项目完成度比较高了（仅限接口层面）

性能方面做一些调整还是必要的

前端性能优化(提升13倍)

:::danger{title="白嫖就是好啊"}
这次又来白嫖Github + DockerHub完成CI/CD!
:::



# 什么是CI/CD？让你的项目变得更加敏捷！

在今天这个快速变化的时代，开发者们需要与时俱进，不断提升自己的工作效率。在这篇文章里，将一起探讨如何使用CI/CD和Github Action让你的项目更加高效，快速响应市场变化。

## 什么是CI？

CI（持续集成，Continuous Integration）是一种软件开发实践，它要求开发者频繁地将代码集成到共享的主干分支中。每次集成都会触发自动化的构建和测试，以便尽早发现和修复问题，减少整体风险。

## 什么是CD？

CD（持续交付和持续部署，Continuous Delivery/Deployment）是一种紧密跟随CI的实践。它要求在一个自动化的、可复制的环境中，持续地将软件交付给客户或部署到生产环境。这样可以确保软件始终处于可交付或可部署的状态。

## 使用CI/CD的目的

采用CI/CD的主要目的是提高软件开发过程的效率和质量，从而加快交付速度，缩短反馈周期，降低风险，提高客户满意度。CI/CD在敏捷开发、DevOps等现代软件开发方法中扮演着核心角色。

# Github Action是什么

Github Action是GitHub提供的一项自动化服务，它允许你在GitHub仓库中直接定义、构建和执行CI/CD流水线。你可以创建自定义的工作流程，以响应各种事件，如代码提交、Pull Request或者定时任务。

## 如何在自己的项目上使用Github Action

1. 在你的GitHub仓库中创建一个名为`.github/workflows`的目录。
2. 在该目录中创建一个YAML文件，如`ci-cd.yml`，来定义你的工作流程。
3. 编辑YAML文件，编写工作流程的各个步骤，如检出代码、构建、测试、部署等。
4. 提交YAML文件到仓库，Github Action会自动执行你定义的工作流程。

## Github + DockerHub等于CI/CD

通过将Github Action与DockerHub等其他服务相结合，你可以更轻松地实现CI/CD。例如，你可以将构建好的Docker镜像推送到DockerHub，然后使用Kubernetes等工具将镜像部署到生产环境。

# 如何利用Github Action实现CI/CD：一个实战案例

在前面的文章中，已经了解了CI/CD的基本概念和Github Action的功能。接下来，将通过一个[实际的Github项目](https://github.com/lihuacai168/AnotherFasterRunne)来详细介绍如何使用Github Action实现CI/CD流程。

以下是整个CI/CD过程的简要概述：

1. 定义workflow
2. 本地修改代码
3. 创建PR（Pull Request）
4. 合并PR
5. workflow自动触发完成CI/CD

具体步骤如下：

## 1. 定义workflow

在你的GitHub仓库中创建一个名为`.github/workflows`的目录，然后创建一个YAML文件，如`ci-cd.yml`，用于定义你的CI/CD流程。具体可以看看[这里](https://github.com/lihuacai168/AnotherFasterRunner/actions)

<img src="https://img.huacai.one/huacai-blog/b973c3918de569cbffea5c045337b877.image.webp" alt="image.png" style="zoom:50%;" />

## 2. 本地修改代码

在本地环境中修改代码并进行测试，确保代码的质量和可用性。

## 3. 创建PR（Pull Request）

将本地修改的代码提交到GitHub仓库，并创建一个PR，以便其他团队成员进行代码审查（呜呜呜，然而我没有其他成员）。

## 4. 合并PR

在代码审查通过后，合并PR到主干分支。

## 5. workflow自动触发完成CI/CD

一旦PR被合并，Github Action会自动触发定义好的workflow。在本案例中，workflow将完成以下任务：

### CI：自动构建Docker镜像，推送到DockerHub

1. 检出代码：Github Action会自动将最新的代码检出到工作环境中。
2. 构建Docker镜像：根据项目中的`Dockerfile`，构建新的Docker镜像。
3. 推送Docker镜像到DockerHub：将构建好的Docker镜像推送到DockerHub，以便其他人可以轻松获取和使用。

### CD：自动拉取最新Docker镜像，启动项目，并重启相关服务

1. 登录部署服务器：通过SSH登录到目标服务器。
2. 拉取最新Docker镜像：从DockerHub拉取最新版本的Docker镜像。
3. 启动项目：运行新的Docker镜像，启动项目实例。
4. 重启相关服务：如果项目依赖其他服务，例如Ngin等，确保这些服务也被正确地重启。

```mermaid
sequenceDiagram
    participant Dev as Developer
    participant Repo as GitHub Repository
    participant GHAction as GitHub Action
    participant DockerHub as Docker Hub
    participant Server as Deployment Server

    Dev->>Repo: Push local changes
    Dev->>Repo: Create Pull Request
    Dev->>Repo: Merge Pull Request
    Repo->>GHAction: Trigger CI/CD workflow
    GHAction->>Repo: Checkout code
    GHAction->>GHAction: Build Docker image
    GHAction->>DockerHub: Push Docker image
    GHAction->>Server: SSH login
    GHAction->>Server: Pull latest Docker image
    GHAction->>Server: Start project instance
    GHAction->>Server: Restart related services
```
在这个时序图中，可以看到整个实战案例中的CI/CD流程。首先，开发者将本地的更改推送到GitHub仓库，并创建并合并Pull Request。当Pull Request被合并时，GitHub Action会自动触发CI/CD工作流程。接下来，GitHub Action会执行一系列操作，包括检出代码、构建Docker镜像、推送镜像到Docker Hub以及登录部署服务器、拉取最新镜像、启动项目实例并重启相关服务。这个时序图可以帮助你更直观地理解CI/CD的过程。

# Github Action的优劣势

### 优势
1. 与GitHub仓库紧密集成，方便使用。
2. 支持丰富的事件触发器和可自定义的工作流程。
3. 免费额度较为充足，适合个人项目和小团队。
4. 有大量的开源Action可供选择，可以节省时间和精力。

### 劣势
1. 对于大型项目和企业级用户，可能需要更高的性能和更多的资源，而Github Action的免费额度有限。
2. 与第三方服务的集成可能不如专业的CI/CD平台灵活。
3. 部分高级功能需要付费使用。

在这里，非常希望听到你关于CI/CD和Github Action的看法。你是否已经在项目中应用了这些实践？你认为它们如何帮助你提高效率和质量？请在评论区留下你的想法，让我们一起交流、学习、进步！

如果你喜欢这篇文章，别忘了点赞、分享和关注我的博客，以便在第一时间获取更多关于科技、编程和创新的精彩内容！我们期待与你一起成长！