39-性能分析（下）：APIServer性能测试和调优实战

news2024/11/27 18:37:37

 

 

在API上线之前，我们需要知道API的性能，以便知道API服务器所能承载的最大请求量、性能瓶颈，再根据业务对性能的要求，来对API进行性能调优或者扩缩容。通过这些，可以使API稳定地对外提供服务，并且让请求在合理的时间内返回。 

API性能测试指标

API性能测试，往大了说其实包括API框架的性能和指定API的性能。 

用来衡量API性能的指标主要有3个：

  • 并发数（Concurrent）：并发数是指某个时间范围内，同时在使用系统的用户个数。广义上的并发数是指同时使用系统的用户个数，这些用户可能调用不同的API；严格意义上的并发数是指同时请求同一个API的用户个数。 
  • 每秒查询数（QPS）：每秒查询数QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。QPS = 并发数 / 平均请求响应时间。
  • 请求响应时间（TTLB）：请求响应时间指的是从客户端发出请求到得到响应的整个时间。这个过程从客户端发起的一个请求开始，到客户端收到服务器端的响应结束。 

这三个指标中，衡量API性能的最主要指标是QPS， 举个例子，单用户100 QPS和100用户100 QPS是两个不同的概念，前者说明API可以在一秒内串行执行100个请求，而后者说明在并发数为100的情况下，API可以在一秒内处理100个请求。当QPS相同时，并发数越大，说明API性能越好，并发处理能力越强。

 

此外，在有些API接口中，也会测试API接口的TPS（Transactions Per Second，每秒事务数）。一个事务是指客户端向服务器发送请求，然后服务器做出反应的过程。 

那么，TPS和QPS有什么区别呢？如果是对一个查询接口（单场景）压测，且这个接口内部不会再去请求其他接口，那么TPS=QPS，否则，TPS≠QPS。如果是对多个接口（混合场景）压测，假设N个接口都是查询接口，且这个接口内部不会再去请求其他接口，QPS=N*TPS。

API性能测试方法

Linux下有很多Web性能测试工具，常用的有Jmeter、AB、Webbench和wrk。每个工具都有自己的特点，IAM项目使用wrk来对API进行性能测试。wrk非常简单，安装方便，测试结果也相对专业，并且可以支持Lua脚本来创建更复杂的测试场景。 

wrk安装方法

wrk的安装很简单，一共可分为两步。

第一步，Clone wrk repo：

$ git clone https://github.com/wg/wrk

第二步，编译并安装：

$ cd wrk
$ make
$ sudo cp ./wrk /usr/bin

wrk使用简介

这里我们来看下wrk的使用方法。wrk使用起来不复杂，执行wrk --help可以看到wrk的所有运行参数：

$ wrk --help
Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  Connections to keep open
    -d, --duration    <T>  Duration of test
    -t, --threads     <N>  Number of threads to use

    -s, --script      <S>  Load Lua script file
    -H, --header      <H>  Add header to request
        --latency          Print latency statistics
        --timeout     <T>  Socket/request timeout
    -v, --version          Print version details

  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

常用的参数有下面这些：

  • -t，线程数（线程数不要太多，是核数的2到4倍就行，多了反而会因为线程切换过多造成效率降低）。
  • -c，并发数。
  • -d，测试的持续时间，默认为10s。
  • -T，请求超时时间。
  • -H，指定请求的HTTP Header，有些API需要传入一些Header，可通过wrk的-H参数来传入。
  • –latency，打印响应时间分布。
  • -s，指定Lua脚本，Lua脚本可以实现更复杂的请求。

然后，我们来看一个wrk的测试结果，并对结果进行解析。

一个简单的测试如下（确保iam-apiserver已经启动，并且开启了健康检查）：

$ wrk -t144 -c30000 -d30s -T30s --latency http://10.0.4.57:8080/healthz
Running 30s test @ http://10.0.4.57:8080/healthz
  144 threads and 30000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   508.77ms  604.01ms   9.27s    81.59%
    Req/Sec   772.48      0.94k   10.45k    86.82%
  Latency Distribution
     50%  413.35ms
     75%  948.99ms
     90%    1.33s
     99%    2.44s
  2276265 requests in 30.10s, 412.45MB read
  Socket errors: connect 1754, read 40, write 0, timeout 0
Requests/sec:  75613.16
Transfer/sec:     13.70MB

下面是对测试结果的解析。

  • 144 threads and 30000 connections：用144个线程模拟20000个连接，分别对应-t和-c参数。
  • Thread Stats是线程统计，包括Latency和Req/Sec。
    • Latency：响应时间，有平均值、标准偏差、最大值、正负一个标准差占比。
    • Req/Sec：每个线程每秒完成的请求数, 同样有平均值、标准偏差、最大值、正负一个标准差占比。
  • Latency Distribution是响应时间分布。
    • 50%：50%的响应时间为413.35ms。
    • 75%：75%的响应时间为948.99ms。
    • 90%：90%的响应时间为1.33s。
    • 99%：99%的响应时间为2.44s。
  • 2276265 requests in 30.10s, 412.45MB read：30.10s完成的总请求数（2276265）和数据读取量（412.45MB）。
  • Socket errors: connect 1754, read 40, write 0, timeout 0：错误统计，会统计connect连接失败请求个数（1754）、读失败请求个数、写失败请求个数、超时请求个数。
  • Requests/sec：QPS。
  • Transfer/sec：平均每秒读取13.70MB数据（吞吐量）。

API Server性能测试实践

 。影响API Server性能的因素有很多，除了iam-apiserver自身的原因之外，服务器的硬件和配置、测试方法、网络环境等都会影响。为了方便你对照性能测试结果，我给出了我的测试环境配置，你可以参考下。

  • 客户端硬件配置：1核4G。
  • 客户端软件配置：干净的CentOS Linux release 8.2.2004 (Core)。
  • 服务端硬件配置：2核8G。
  • 服务端软件配置：干净的CentOS Linux release 8.2.2004 (Core)。
  • 测试网络环境：腾讯云VPC内访问，除了性能测试程序外，没有其他资源消耗型业务程序。

测试架构如下图所示：

性能测试脚本介绍

在做API Server的性能测试时，需要先执行wrk，生成性能测试数据。为了能够更直观地查看性能数据，我们还需要以图表的方式展示这些性能数据。 我使用 gnuplot 工具来自动化地绘制这些性能图，为此我们需要确保Linux服务器已经安装了 gnuplot 工具。 

$ sudo yum -y install gnuplot

在这一讲的测试中，我会绘制下面这两张图，通过它们来观测和分析API Server的性能。

  • QPS & TTLB图：X轴为并发数（Concurrent），Y轴为每秒查询数（QPS）和请求响应时间（TTLB）。
  • 成功率图：X轴为并发数（Concurrent），Y轴为请求成功率。

为了方便你测试API接口性能，我将性能测试和绘图逻辑封装在scripts/wrktest.sh脚本中，你可以在iam源码根目录下执行如下命令，生成性能测试数据和性能图表：

$ scripts/wrktest.sh http://10.0.4.57:8080/healthz

 

接下来，我再来介绍下wrktest.sh性能测试脚本，并给出一个使用示例。

wrktest.sh性能测试脚本，用来测试API Server的性能，记录测试的性能数据，并根据性能数据使用gnuplot绘制性能图。

wrktest.sh也可以对比前后两次的性能测试结果，并将对比结果通过图表展示出来。wrktest.sh会根据CPU的核数自动计算出适合的wrk启动线程数（-t）：CPU核数 * 3。

wrktest.sh默认会测试多个并发下的API性能，默认测试的并发数为200 500 1000 3000 5000 10000 15000 20000 25000 50000。你需要根据自己的服务器配置选择测试的最大并发数，我因为服务器配置不高（主要是8G内存在高并发下，很容易就耗尽），最大并发数选择了50000。如果你的服务器配置够高，可以再依次尝试下测试 100000 、200000 、500000 、1000000 并发下的API性能。

wrktest.sh的使用方法如下：

$ scripts/wrktest.sh -h

Usage: scripts/wrktest.sh [OPTION] [diff] URL
Performance automation test script.

  URL                    HTTP request url, like: http://10.0.4.57:8080/healthz
  diff                   Compare two performance test results

OPTIONS:
  -h                     Usage information
  -n                     Performance test task name, default: apiserver
  -d                     Directory used to store performance data and gnuplot graphic, default: _output/wrk

Reprot bugs to <colin404@foxmail.com>.

wrktest.sh提供的命令行参数介绍如下。

  • URL：需要测试的API接口。
  • diff：如果比较两次测试的结果，需要执行wrktest.sh diff 。
  • -n：本次测试的任务名，wrktest.sh会根据任务名命名生成的文件。
  • -d：输出文件存放目录。
  • -h：打印帮助信息。

下面，我来展示一个wrktest.sh使用示例。

wrktest.sh的主要功能有两个，分别是运行性能测试并获取结果和对比性能测试结果。下面我就分别介绍下它们的具体使用方法。

  1. 运行性能测试并获取结果

执行如下命令：

$ scripts/wrktest.sh http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 200 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 500 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 1000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 3000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 5000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 10000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 15000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 20000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 25000 http://10.0.4.57:8080/healthz
Running wrk command: wrk -t3 -d300s -T30s --latency -c 50000 http://10.0.4.57:8080/healthz

Now plot according to /home/colin/_output/wrk/apiserver.dat
QPS graphic file is: /home/colin/_output/wrk/apiserver_qps_ttlb.png
Success rate graphic file is: /home/colin/_output/wrk/apiserver_successrate.pngz

上面的命令默认会在_output/wrk/目录下生成3个文件：

  • apiserver.dat，wrk性能测试结果，每列含义分别为并发数、QPS 平均响应时间、成功率。
  • apiserver_qps_ttlb.png，QPS&TTLB图。
  • apiserver_successrate.png，成功率图。

这里要注意，请求URL中的IP地址应该是腾讯云VPC内网地址，因为通过内网访问，不仅网络延时最低，而且还最安全，所以真实的业务通常都是内网访问的。

  1. 对比性能测试结果

假设我们还有另外一次API性能测试，测试数据保存在 _output/wrk/http.dat 文件中。

执行如下命令，对比两次测试结果：

$ scripts/wrktest.sh diff _output/wrk/apiserver.dat _output/wrk/http.dat

apiserver.dat和http.dat是两个需要对比的Wrk性能数据文件。上述命令默认会在_output/wrk目录下生成下面这两个文件：

  • apiserver_http.qps.ttlb.diff.png，QPS & TTLB对比图。
  • apiserver_http.success_rate.diff.png，成功率对比图。

关闭Debug配置选项

在测试之前，我们需要关闭一些Debug选项，以免影响性能测试。

执行下面这两步操作，修改iam-apiserver的配置文件：

  • 将server.mode设置为release，server.middlewares去掉dump、logger中间件。
  • 将log.level设置为info，log.output-paths去掉stdout。

因为我们要在执行压力测试时分析程序的性能，所以需要设置feature.profiling为true，以开启性能分析。修改完之后，重新启动iam-apiserver。

使用wrktest.sh测试IAM API接口性能

关闭Debug配置选项之后，就可以执行wrktest.sh命令测试API性能了（默认测试的并发数为200 500 1000 3000 5000 10000 15000 20000 25000 50000）:

$ scripts/wrktest.sh http://10.0.4.57:8080/healthz

生成的QPS & TTLB图和成功率图分别如下图所示：

图片

上图中，X轴为并发数（Concurrent），Y轴为每秒查询数（QPS）和请求响应时间（TTLB）。

上图中，X轴为并发数（Concurrent），Y轴为请求成功率。

通过上面两张图，你可以看到，API Server在并发数为200时，QPS最大；并发数为500，平均响应时间为56.33ms，成功率为 100.00% 。在并发数达到1000时，成功率开始下降。一些详细数据从图里看不到，你可以直接查看apiserver.dat文件，里面记录了每个并发下具体的QPS、TTLB和成功率数据。

现在我们有了API Server的性能数据，那么该API Server的QPS处于什么水平呢？一方面，你可以根据自己的业务需要来对比；另一方面，可以和性能更好的Web框架进行对比，总之需要有个参照。

这里用net/http构建最简单的HTTP服务器，使用相同的测试工具和测试服务器，测试性能并作对比。HTTP服务源码为（位于文件tools/httptest/main.go中）：

package main

import (
	"fmt"
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
		message := `{"status":"ok"}`
		fmt.Fprint(w, message)
	})

	addr := ":6667"
	fmt.Printf("Serving http service on %s\n", addr)
	log.Fatal(http.ListenAndServe(addr, nil))
}

我们将上述HTTP服务的请求路径设置为/healthz，并且返回{"status":"ok"}，跟API Server的接口返回数据完全一样。通过这种方式，你可以排除因为返回数据大小不同而造成的性能差异。

可以看到，该HTTP服务器很简单，只是利用net/http包最原生的功能，在Go中几乎所有的Web框架都是基于net/http包封装的。既然是封装，肯定比不上原生的性能，所以我们要把它跟用net/http直接启动的HTTP服务接口的性能进行对比，来衡量我们的API Server性能。

我们需要执行相同的wrk测试，并将结果跟API Server的测试结果进行对比，将对比结果绘制成对比图。具体对比过程可以分为3步。

第一步，启动HTTP服务。

在iam源码根目录下执行如下命令：

$ go run tools/httptest/main.go

第二步，执行wrktest.sh脚本，测试该HTTP服务的性能：

$ scripts/wrktest.sh -n http http://10.0.4.57:6667/healthz

上述命令会生成 _output/wrk/http.dat 文件。

第三步，对比两次性能测试数据：

$ scripts/wrktest.sh diff _output/wrk/apiserver.dat _output/wrk/http.dat

生成的两张对比图表，如下所示：

图片

图片

通过上面两张对比图，我们可以看出，API Server在QPS、响应时间和成功率上都不如原生的HTTP Server，特别是QPS，最大QPS只有原生HTTP Server 最大QPS的13.68%，性能需要调优。

API Server性能分析

 

在分析前我们需要对API Server加压，在加压的情况下，API接口的性能才更可能暴露出来，所以继续执行如下命令：

$ scripts/wrktest.sh http://10.0.4.57:8080/healthz

在上述命令执行压力测试期间，可以打开另外一个Linux终端，使用go tool pprof工具分析HTTP的profile文件：

$ go tool pprof http://10.0.4.57:8080/debug/pprof/profile

执行完go tool pprof后，因为需要采集性能数据，所以该命令会阻塞30s。

在pprof交互shell中，执行top -cum查看累积采样时间，我们执行top30 -cum，多观察一些函数：

(pprof) top20 -cum
Showing nodes accounting for 32.12s, 39.62% of 81.07s total
Dropped 473 nodes (cum <= 0.41s)
Showing top 20 nodes out of 167
(pprof) top30 -cum
Showing nodes accounting for 11.82s, 20.32% of 58.16s total
Dropped 632 nodes (cum <= 0.29s)
Showing top 30 nodes out of 239
      flat  flat%   sum%        cum   cum%
     0.10s  0.17%  0.17%     51.59s 88.70%  net/http.(*conn).serve
     0.01s 0.017%  0.19%     42.86s 73.69%  net/http.serverHandler.ServeHTTP
     0.04s 0.069%  0.26%     42.83s 73.64%  github.com/gin-gonic/gin.(*Engine).ServeHTTP
     0.01s 0.017%  0.28%     42.67s 73.37%  github.com/gin-gonic/gin.(*Engine).handleHTTPRequest
     0.08s  0.14%  0.41%     42.59s 73.23%  github.com/gin-gonic/gin.(*Context).Next (inline)
     0.03s 0.052%  0.46%     42.58s 73.21%  .../internal/pkg/middleware.RequestID.func1
         0     0%  0.46%     41.02s 70.53%  .../internal/pkg/middleware.Context.func1
     0.01s 0.017%  0.48%     40.97s 70.44%  github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1
     0.03s 0.052%  0.53%     40.95s 70.41%  .../internal/pkg/middleware.LoggerWithConfig.func1
     0.01s 0.017%  0.55%     33.46s 57.53%  .../internal/pkg/middleware.NoCache
     0.08s  0.14%  0.69%     32.58s 56.02%  github.com/tpkeeper/gin-dump.DumpWithOptions.func1
     0.03s 0.052%  0.74%     24.73s 42.52%  github.com/tpkeeper/gin-dump.FormatToBeautifulJson
     0.02s 0.034%  0.77%     22.73s 39.08%  github.com/tpkeeper/gin-dump.BeautifyJsonBytes
     0.08s  0.14%  0.91%     16.39s 28.18%  github.com/tpkeeper/gin-dump.format
     0.21s  0.36%  1.27%     16.38s 28.16%  github.com/tpkeeper/gin-dump.formatMap
     3.75s  6.45%  7.72%     13.71s 23.57%  runtime.mallocgc
     ...

因为top30内容过多，这里只粘贴了耗时最多的一些关联函数。从上面的列表中，可以看到有ServeHTTP类的函数，这些函数是gin/http自带的函数，我们无需对此进行优化。

还有这样一些函数：

.../gin.(*Context).Next (inline)
.../internal/pkg/middleware.RequestID.func1
.../internal/pkg/middleware.Context.func1
github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1
.../internal/pkg/middleware.LoggerWithConfig.func1
.../internal/pkg/middleware.NoCache
github.com/tpkeeper/gin-dump.DumpWithOptions.func1

可以看到，middleware.RequestID.func1、middleware.Context.func1、gin.CustomRecoveryWithWriter.func1、middleware.LoggerWithConfig.func1等，这些耗时较久的函数都是我们加载的Gin中间件。这些中间件消耗了大量的CPU时间，所以我们可以选择性加载这些中间件，删除一些不需要的中间件，来优化API Server的性能。
假如我们暂时不需要这些中间件，也可以通过配置iam-apiserver的配置文件，将server.middlewares设置为空或者注释掉，然后重启iam-apiserver。重启后，再次执行wrktest.sh测试性能，并跟原生的HTTP Server性能进行对比，对比结果如下面2张图所示：

图片

图片

可以看到，删除无用的Gin中间件后，API Server的性能有了很大的提升，并发数为200时性能最好，此时QPS为47812，响应时间为4.33``ms，成功率为100.00``%。在并发数为50000的时候，其QPS是原生HTTP Server的75.02%。

API接口性能参考

不同团队对API接口的性能要求不同，同一团队对每个API接口的性能要求也不同，所以并没有一个统一的数值标准来衡量API接口的性能，但可以肯定的是，性能越高越好。我根据自己的研发经验，在这里给出一个参考值（并发数可根据需要选择），如下表所示：

API Server性能测试注意事项

在进行API Server性能测试时，要考虑到API Server的性能影响因素。影响API Server性能的因素很多，大致可以分为两类，分别是Web框架的性能和API接口的性能。另外，在做性能测试时，还需要确保测试环境是一致的，最好是一个干净的测试环境。

Web框架性能

 

 当整个Go后端服务开发完成之后，在上线之前，我们还需要对Web框架再次进行测试，确保按照我们最终的使用方式，Web框架仍然能够保持优秀的性能和稳定性。

我们通常会通过API接口来测试Web框架的性能，例如健康检查接口/healthz。我们需要保证该API接口足够简单，API接口里面不应该掺杂任何逻辑，只需要象征性地返回一个很小的返回内容即可。比如，这一讲中我们通过/healthz接口来测试Web框架的性能：

s.GET("/healthz", func(c *gin.Context) {
    core.WriteResponse(c, nil, map[string]string{"status": "ok"})
})

接口中只调用了core.WriteResponse函数，返回了{"status":"ok"}。这里使用core.WriteResponse函数返回请求数据，而不是直接返回ok字符串，这样做是为了保持API接口返回格式统一。

API接口性能

 接口性能，我们会使用wrk这类HTTP压力测试工具，来模拟多个API请求，进而分析API的性能。

因为会模拟大量的请求，这时候测试写类接口，例如Create、Update、Delete等会存在一些问题，比如可能在数据库中插入了很多数据，导致磁盘空间被写满或者数据库被压爆。所以，针对写类接口，我们可以借助单元测试，来测试其性能。根据我的开发经验，写类接口通常不会有性能问题，反而读类接口更可能遇到性能问题。针对读类接口，我们可以使用wrk这类HTTP压力测试工具来进行测试。

 

总结

在项目上线前，我们需要对API接口进行性能测试。通常API接口的性能延时要小于 500ms ，如果大于这个值，需要考虑优化性能。在进行性能测试时，需要确保每次测试都有一个一致的测试环境，这样不同测试之间的数据才具有可对比性。这一讲中，我推荐了一个比较优秀的性能测试工具 wrk ，我们可以编写shell脚本，将wrk的性能测试数据自动绘制成图，方便我们查看、对比性能。

如果发现API接口的性能不符合预期，我们可以借助 go tool pprof 工具来分析性能。在 go tool pprof 交互界面，执行 top -cum 命令查看累积采样时间，根据累积采样时间确定影响性能的代码，并优化代码。优化后，再进行测试，如果不满足，继续分析API接口的性能。如此往复，直到API接口的性能满足预期为止。

课后练习

  1. 选择一个项目，并使用wrktest.sh脚本测试其API接口，分析并优化API接口的性能.
  2. 思考下，在你的工作中，还有没有其他好的API接口性能分析方法.

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1582109.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

java算法day49 | 动态规划part10 ● 121. 买卖股票的最佳时机 ● 122.买卖股票的最佳时机II

java算法day49 | 动态规划part10 ● 121. 买卖股票的最佳时机 ● 122.买卖股票的最佳时机II

121. 买卖股票的最佳时机 class Solution {public int maxProfit(int[] prices) {//1、定义dp数组&#xff0c;表示第i天持股票的状态dp[i][0]表示持有股票dp[i][1]表示不持有股票int[][] dpnew int[prices.length][2];//3、初始化数组dp[0][1]0;dp[0][0]-prices[0];//4、遍历顺…
阅读更多...
Linux--进程的概念（二）

Linux--进程的概念（二）

目录 一、进程的优先级1.1 基本概念1.2 查看进程优先级1.3 PRI&NI1.4 如何更改进程的优先级1.4.1 用top命令更改进程的nice1.4.2 用renice命令更改进程的nice 1.5 其他概念 二、环境变量2.1 基本概念2.2 常见的环境变量2.3 查看环境变量2.3.1 测试PATH2.3.2 测试HOME2.3.3 …
阅读更多...
Android14之智能指针的弱引用、强引用、弱指针、强指针用法区别及代码实例(二百零五)

Android14之智能指针的弱引用、强引用、弱指针、强指针用法区别及代码实例(二百零五)

简介&#xff1a; CSDN博客专家&#xff0c;专注Android/Linux系统&#xff0c;分享多mic语音方案、音视频、编解码等技术&#xff0c;与大家一起成长&#xff01; 优质专栏&#xff1a;Audio工程师进阶系列【原创干货持续更新中……】&#x1f680; 优质专栏&#xff1a;多媒…
阅读更多...
LTC4054 充电指示灯转灯电路

LTC4054 充电指示灯转灯电路

由于这个芯片只有CHRG# 引脚&#xff0c;不像4056 那样两个引脚能分别接一个LED&#xff0c;要实现充电指示就必须自己整整外围电路。先说明一下&#xff0c;网上常见的这种接法&#xff1a; 一个LED 直连CHRG# 引脚&#xff0c;我试了是不行的&#xff0c;即使充满电&#xff…
阅读更多...
【国际会议火热征稿】2024年应用经济学、管理科学与社会国际学术会议（ICAEMSS 2024）

【国际会议火热征稿】2024年应用经济学、管理科学与社会国际学术会议（ICAEMSS 2024）

会议简介 2024年应用经济学、管理科学与社会国际学术会议将聚焦应用经济学和管理科学的前沿问题&#xff0c;深入探讨社会变革中的经济管理与科学应用。参会者将分享最新研究成果&#xff0c;交流学术观点&#xff0c;共同探索经济、管理与社会的融合发展之路。本次会议旨在推…
阅读更多...
Zotero + Markdown论文工作流

Zotero + Markdown论文工作流

文章目录 关键步骤Zotero Better BibTeXObsidian Citekey Plugin & WrittingPandoc Export 关键步骤 在Zotero中&#xff0c;使用Better BibTex生成.bib文件&#xff0c;用于提取索引信息。由于后续需要使用pandoc将markdown转换为word或者LaTeX&#xff0c;所以Better Bi…
阅读更多...
记Kubernetes（k8s）：访问 Prometheus UI界面:Warning: Error fetching server time

记Kubernetes（k8s）：访问 Prometheus UI界面:Warning: Error fetching server time

记Kubernetes&#xff08;k8s&#xff09;&#xff1a;访问 Prometheus UI界面:Warning: Error fetching server time 1、报错详情2、解决3、再次访问 PrometheusUI界面 &#x1f496;The Begin&#x1f496;点点关注&#xff0c;收藏不迷路&#x1f496; 1、报错详情 Warning:…
阅读更多...
Linux启动过程、启动脚本目录介绍及检测思路分析

Linux启动过程、启动脚本目录介绍及检测思路分析

一、Linux系统启动过程 1、启动流程&#xff1a; Linux系统的启动过程可以分为5个阶段&#xff1a;内核的引导、运行init、系统初始化、建立终端、用户登录系统。 2、init程序的类型&#xff1a; 1&#xff09;SysV&#xff1a;init&#xff0c;CentOS 5之前&#xff0c;配置文…
阅读更多...
socuretree远程分支没有同步问题

socuretree远程分支没有同步问题

1、选择命令行模式 2、输入git remote update origin --prune 并回车 git remote update origin --prune 是 Git 命令&#xff0c;用于从远程仓库更新本地分支&#xff0c;并删除本地已经不存在于远程仓库的远程跟踪分支
阅读更多...
ADP-2-20+ 信号调节 20MHz-2GHzRF功分器 合路器

ADP-2-20+ 信号调节 20MHz-2GHzRF功分器 合路器

ADP-2-20 是一款由Mini-Circuits公司出产的功分器&#xff08;power divider&#xff09;。这款功分器的工作温度规模为-40C至85C&#xff0c;贮存温度规模为-55C至100C。作为分路器&#xff0c;它的电源输入最高可达1W&#xff0c;内部功耗最大为0.125W。假如超越这些限制&…
阅读更多...
【Cesium学习笔记】一、加载Cesium并更换天地图底图

【Cesium学习笔记】一、加载Cesium并更换天地图底图

【Cesium学习笔记】一、加载Cesium 一、加载Cesium二、用Viewer显示地球三、更换天地图底图 Ps:本教程所有代码于同一个工程中&#xff0c;运行npm run dev默认首页为App.vue&#xff0c;只需替换App.vue的内容即可切换不同页面。 一、加载Cesium 本项目使用nvm管理node版本&…
阅读更多...
李沐23_LeNet——自学笔记

李沐23_LeNet——自学笔记

手写的数字识别 知名度最高的数据集&#xff1a;MNIST 1.训练数据&#xff1a;50000 2.测试数据&#xff1a;50000 3.图像大小&#xff1a;28✖28 4.10类 总结 1.LeNet是早期成功的神经网络 2.先使用卷积层来学习图片空间信息 3.使用全连接层来转换到类别空间 代码实现…
阅读更多...
Al+医学，用这个中文多模态医学大模型帮你看胸片

Al+医学，用这个中文多模态医学大模型帮你看胸片

随着人工智能技术的飞速发展&#xff0c;AI 在医学领域的应用已经成为现实。特别是在医学影像诊断方面&#xff0c;AI 大模型技术展现出了巨大的潜力和价值&#xff0c;但目前针对中文领域医学大多模态大模型还较少。 今天为大家介绍的这款 XrayGLM&#xff0c;就是由澳门理工…
阅读更多...
HackTheBox-Machines--Soccer

HackTheBox-Machines--Soccer

文章目录 1 信息收集2 CVE-2021-45010 漏洞利用3 横向移动4 权限提升 Soccer 测试过程 1 信息收集 a.端口扫描&#xff1a;发现22、80、9091端口    b.目录扫描&#xff1a;http://soccer.htb/tiny/    c.子域爆破    d.信息泄漏 nmap -sC -sV 10.129.87.151端口扫描结…
阅读更多...
【APUE】网络socket编程温度采集智能存储与上报项目技术------多路复用

【APUE】网络socket编程温度采集智能存储与上报项目技术------多路复用

作者简介&#xff1a; 一个平凡而乐于分享的小比特&#xff0c;中南民族大学通信工程专业研究生在读&#xff0c;研究方向无线联邦学习 擅长领域&#xff1a;驱动开发&#xff0c;嵌入式软件开发&#xff0c;BSP开发 作者主页&#xff1a;一个平凡而乐于分享的小比特的个人主页…
阅读更多...
JVM—jps、jstat、jinfo、jmap、jstack的使用

JVM—jps、jstat、jinfo、jmap、jstack的使用

JVM—jps、jstat、jinfo、jmap、jstack的使用 jps jps全称&#xff1a;Java Virtual Machine Process Status Tool 可以查看Java进程&#xff0c;相当于Linux下的ps命令&#xff0c;只不过它只列出Java进程。 jps:列出Jav程序ID和Main函数名称 jps -q:只输出进程ID jps -m …
阅读更多...
【星期计算】蓝桥杯

【星期计算】蓝桥杯

–> 因为这里是结果填空题&#xff0c;我们直接暴力用java自带的BigInteger类。 /*** 试题 A: 星期计算** 本题总分&#xff1a;5 分* 【问题描述】* 已知今天是星期六&#xff0c;请问20的22次方天后是星期几&#xff1f;* 注意用数字 1 到 7 表示星期一到星期日。* * 【答…
阅读更多...
Adobe Photoshop 2024 v25.6强大的图形编辑工具

Adobe Photoshop 2024 v25.6强大的图形编辑工具

Adobe Photoshop 2024是一款非常强大的图像处理软件&#xff0c;具有丰富的功能和工具&#xff0c;可以满足各种图像处理需求。 软件下载&#xff1a;Adobe Photoshop 2024 v25.6中文激活版 它不仅支持基本的图像编辑和调整&#xff0c;还具有高级的特性&#xff0c;如智能对象…
阅读更多...
自定义类型—结构体

自定义类型—结构体

目录 1 . 结构体类型的声明 1.1 结构的声明 1.2 结构体变量的创建与初始化 1.3 结构体的特殊声明 1.4 结构体的自引用 2. 结构体内存对齐 2.1 对齐规则 2.2 为什么存在内存对齐 2.3 修改默认对齐数 3. 结构体传参 4.结构体实现位段 4.1 位段的内存分配 1 . 结构体类…
阅读更多...
w1r3s 靶机学习

w1r3s 靶机学习

w1r3s 靶机学习 0x01 IP C for command kali ip 10.10.10.128victim ip 10.10.10.1290x02 开扫 C sudo nmap -sn 10.10.10.0/24-sn 多一步入侵和轻量级侦察 发送四项请求 -sL 列表扫描&#xff0c;多用于探测可用ip&#xff0c;广播扫描 –send-ip 时间戳请求&#xff0…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023