最近的 Taurus.MVC 版本，对性能这一块有了不少优化，因此准备进行一下压测，来测试并记录一下 Taurus.MVC 框架的性能，以便后续持续优化改进。

今天先压测 .NET Core 版本，后续有时间再压测一下.NET 版本。

下面来看不同场景下的压测结果，以下测试结果会由两台电脑进行分别测试。

一、旧电脑环境：

程序在 .NET8 编绎，以 Kestrel 为主机直接运行在 Window 环境：

1、测试 Window 11 下，单机ab工具压测：

由于ab工具占用资源不多，发起的并发能力也有限，先用它进行本机压测，试试水。

ab的版本信息：

A、先测试单线程的运行性能（简单接口返回，控制台带日志输出）：

测试结果：并发数1，qps = 3263

看一下程序运行的时间：

从程序打印的日志上看，接口执行时间仅有0.03毫秒，理论值单线程压测是可以达到1000/0.0345= 28089，去掉控制器日志输出，还能再提升1下，再配置个64核cpu，就是传说中的轻轻松松的单机百万qps了。

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回，控制台带日志输出）：

测试结果：

没办法，只能压 2 个并发链接，CPU 跑满了，程序占40%多，ab也占了40%多，说好的ab不吃资源的，直接cpu拉走一半，呵呵。

C、我们关闭日志输出，重新看看上面的两个能测试出多少（简单接口返回，控制台无日志输出）：

我们添加以下代码，关闭 Kestrel 默认的控制台信息输出：

【后续的测试，都保持控制器日志关闭】

重新编绎后，进行重新测试：

测试结果：并发数1，qps = 3595

关闭日志，提升了300多，后续测试，将会保持控制台日志的关闭。

测试结果：并发数 2，qps = 5765

接下来，我们将接口调整一下，单纯的返回 Hello World 没啥看头，改成常规一些。

D、使用 CYQ.Data 读数据库，输出 Json，来看看压测结果（读数据库接口，控制台无日志输出）

测试代码：

运行结果：返回一条数据：

下面直接进行压测结果：并发数 2 ，qps = 5470，和未关闭日志输出时差不多。

小结：

下面更换 wrk 进行测试，由于 wrk 只能在 linux 中运行，因此在本机上，开启了虚拟机。

2、测试 Window 11 下，虚拟机wrk工具压测：（读数据库输出，控制台无日志输出）

虚拟机环境：

分完虚拟机后，本机就剩下 4 核了，再去掉打开任务管理器，就占掉了10%的cpu，我了个去，当个3核用了。

不过问题不大，尽管测就是了，为了保持接口的通用性，继续使用读数据库输出 Json 的接口：

先使用1线程1并发测试试试水：

测试结果：qps = 1518

测试过程，通过虚拟机（top 指令）和Windows（任务管理器）观察 cpu，发现没怎么动，看来 wrk 要跑满性能，得加量。

我们给虚拟机分了2个核，不能浪费，要跑满它，于是不断调整参数：

测试结果：qps = 23303

从测试结果观察，wrk 更能压测出性能的极限，当然，这是 wrk 的极限，不是程序的极限。

因为整个压测过程，程序只占了30%左右的cpu，但没办法，cpu 让其它资源给吃光了。

我们知道，.NET Core 的程序，跑在 Linux 下，能会有更优的性能，不过不急先。

由于本机资源有限，干扰程序较多，这里打算拿出我的新电脑，来进行重新测试，看看程序在新电脑的表现如何。

二、新电脑环境：

接下来，我们看看新电脑的表现如何，使用一样的程序：

1、测试 Window 11 下，单机ab工具压测：

A、先测试单线程的运行性能（简单接口返回，控制台无日志输出）：

测试结果：并发数1，qps = 11389

B、我们调整一下参数，看看ab在单机下能压出多少来（简单接口返回，控制台无日志输出）：

测试结果：并发数4，qps = 18247

看来 ab 不行啊，压不出结果，程序的cpu才跑了不到2%。

小结：

2、测试 Window 11 下，虚拟机wrk工具压测：（简单接口，控制台无日志输出）

虚拟机环境：

先给虚拟机2核，本机剩下 12 核了，可以好好压一下了。

测试结果：1并发，qps = 14084

和 ab 一样，一个链接并发压不出什么效果，加大效果看看。

测试结果：qps = 84306

压测试过程，观察两个cpu，虚拟机（110%-130%，2核还没跑满），程序只跑16%-20%，整体40-50%左右，感觉还能往上跑。

估计是压力不够，试着分给虚拟机多2核，看看有没有效果。

虚拟机环境：

继续压测试：

测试结果：qps = 105462

之前压测时间在10s-20s，qps 都在9万多，把压测时间拉长到1分钟，超过了10万了。

看来把压测时间拉长，qps 会高一点。

测试过程中，虚拟机CPU（在180%左右，给了4核，也不顶用，没能跑满），程序占用CPU（20%左右）。

还是跑不满，没办法，压力上不去了，只好换个口味测试。

重新压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012 安装在Window 11 本机）：

接口的调用输出：

进行压测：

测试结果：qps = 73122

再换一个，直接压 MVC 界面，看看效果。

这是压测试的 Taurus.MVC 的主界面：

修改压测路径：

测试结果：qps = 39349

这时候观察，虽然取得了不错的结果，但 CPU 跑满100%了，也有918个超时，看来呈现的加载与呈现，很消耗计算量。

到了最后的步骤了，.NET Core 程序，还是得放到 Linux 系统下跑看看效果 ，复制一台虚拟机，用来部署 .NET Core 程序。

3、测试 CentOS 7 下，虚拟机 wrk 工具压测：

新的虚拟机环境：

1、测试接口：直接压测 CYQ.Data 读数据库转Json输出的接口（数据库mssql2012安装在Window 11 系统）：

测试结果：qps = 80831

观察CPU：压测虚拟机（130%左右，用了1.3个核左右），应用程序虚拟机（450%左右，用了4.5个核左右）

2、测试接口：直接测试简单接口

测试结果：qps = 105994

观察CPU：和上一个结果差不多，只用了虚拟机的50%左右，就是部署在Linux 上，随便调整参数，都轻松10万+。

总结：

对于 API 压测：

旧电脑轻松就打满CPU，主要是被ab和其它应用吃了资源，所以压测上不去，去掉虚拟机两核后，在读数据库转Json输出的情况下，压出了2万3的qps。

新电脑上限太高，wrk 都压不住，上10万+了，CPU 也才20%左右，可见一个高效的CPU对并发的提升是多么明显。

新电脑在读数据库转Json输出的情况下，也有8万+的qps，这个3倍左右的效率，明显的有点明显了。

最后部署在 Linux，可以感觉性能明显比 Window 运行高一些，Window 需要小小调优参数才10万+，而 Linux 上随便调都10万+。

但因wrk给的压力也有限，10万+后无法再测试了，听说 ulimit -n 命令可以解锁，发起更大的并发，这个下次再试了。

对于 MVC 压测：

明显感觉 MVC 的计算量大了很多，wrk 提供的压力已足够跑满CPU，极限跑出近4万的qps，感觉后续应该还能小优化一下。

整体来说，今天的压力测试结果，除了压测试MVC界面，CPU 都没能跑满整机的30%，心累啊，先就到这里了。

附本文的运行程序：

TaurusMVC运行程序下载 - 解压后可直接运行 Taurus.View.exe，欢迎下载自行测试【需要.NET 8 运行环境】