mysql性能测试工具——tpcc-mysql

在centos7.9上安装的
下载源码包，解压安装

tar xf tpcc-mysql-src.tar

cd tpcc-mysql/src

yum install gcc mysql-devel -y

make

会生成两个二进制工具tpcc_load（提供初始化数据的功能）和tpcc_start(进行压力测试)
[root@nfs-server src]# cd ..
[root@nfs-server tpcc-mysql]# ls
add_fkey_idx.sql drop_cons.sql schema2 tpcc_load
count.sql load.sh scripts tpcc_start
create_table.sql README src
3、tpcc测试前准备，初始化数据库
在其他的服务器上连接到mysql服务器上创建tpcc库
需要在测试的服务器上创建tpcc的库
docker exec -it cs bash
mysql -uroot -p’sc@123456’
create database tpcc;
exit exit
[root@docker tpcc-mysql]# pwd
/root/tpcc-mysql 当前所在的文件夹
[root@docker tpcc-mysql]# ls
add_fkey_idx.sql create_table.sql load.sh schema2 src tpcc_start
count.sql drop_cons.sql README scripts tpcc_load
远程连接数据库指令：mysql -h 192.168.159.142 -P 3309 -uroot -p'sc@123456'
[root@docker tpcc-mysql]# mysql -h 192.168. 159.142 -P 3309 -uroot -p'sc@123456' tpcc < create_table.sql 在tpcc库里导入表
[root@docker tpcc-mysql]# mysql -h 192.168. 159.142 -P 3309 -uroot -p'sc@123456' tpcc < add_fkey_idx.sql 建立外键和索引

4、加载数据
注意：server是要测试的服务器，db，user，password是要测的服务器上mysql的信息
./tpcc_load [server] [db] [user] [password] [warehouse]
服务器名 数据库名 用户名 密码 仓库数量
./tpcc_load 192.168.159.142:3309 tpcc root 'sc@123456' 150真实测试中，数据库仓库一般不少于100个，如果配置了ssd，建议最少不低于1000个
5.真正模拟去访问数据库，测试性能
[root@docker tpcc-mysql]#** ./tpcc_start -h 192.168.159.142 -P 3309 -d tpcc -u root -p sc@123456 -w 10 -c 12 -r 10 -l 60 -f test0.log -t test1.log - >test0.out**（输出会重定向到test0.out 存放测试的结果） 模拟对100个仓库(-w 100)，并发128个线程(-c 128)，预热5分钟(-r 300)，持续压测1小时(-l 3600)

-w warehouses ：仓库数量
-c connections：并发线程数(建议大一点 100 模拟同时一百个人访问)
-r warmup_time：指定预热时间，以秒为单位，默认是 10 秒，主要目的是为了将数据加载到内存。
-l running_time：指定测试执行的时间，以秒为单位，默认是 20 秒。
-i report_interval：指定生成报告的间隔时间。
-f report_file：将测试中各项操作的记录输出到指定文件内保存。
-t trx_file：输出更详细的操作信息到指定文件内保存。

1. 去看容器的资源消耗 docker stats 并在宿主机里使用top查看cpu和内存的消耗

TPCC测试结果的主要指标
事务吞吐量（Transactions Per Minute, TPM）：衡量数据库系统处理事务能力的关键指标，表示系统每分钟能够完成的事务数量。高吞吐量表明系统能够高效地处理大量并发事务。
响应时间（Response Time）：表示系统处理单个事务所需的时间。
通常关注90%或99%的事务的响应时间，即90%或99%的事务都能在多少时间内完成。
较短的响应时间意味着系统能够更快地响应用户请求。
事务成功率：表示成功完成的事务占总事务数的比例。
高成功率表明系统稳定运行，错误率低。
测试结果分析
在TPCC测试结果中，通常会包含以下几个关键部分：
热身阶段（Ramp-Up Time）：测试开始前准备阶段，用于预热系统，确保系统达到稳定状态。
测量阶段：实际测试阶段，系统按照预定的负载运行，并收集各项性能指标。
结果输出：测试完成后系统输出详细测试结果，包括吞吐量、响应时间、事务成功率等。
ECS弹性伸缩云服务器 elastic cloud server
云服务器的配置上cpu 内存 磁盘等资源可以调整

如何想再次测试看到效果
需要去删除tpcc库，然后重新导入表和索引数据
TPCC 测试要求下面状态必须为 OK
<Constraint Check> (all must be [OK])
[transaction percentage]
Payment: 43.48% (>=43.0%) [OK] # 要求支付业务占比
Order-Status: 4.35% (>= 4.0%) [OK] # 要求支付业务占比
Delivery: 4.35% (>= 4.0%) [OK] # 物流相关业务占比
Stock-Level: 4.35% (>= 4.0%) [OK] # 库存相关业务占比
[response time (at least 90% passed)] #都ok

ab测试工具用来测试网站压力

[root@docker tpcc-mysql]# yum install httpd-tools -y
docker run -d -p 9900:80 --name liu-nginx --cpu-shares 200 -m 50000000 nginx
安全组： 本质是一个防火墙软件 ---》阻止客户机访问服务器
需要在服务器里打开相关端口号，客户机才可以访问
默认只是允许访问22号端口
开发9900端口

[root@docker tpcc-mysql]# ab -c 100 -n 10000 http://8.219.110.232:9900/ （100个用户同时进行10000个进程 可逐步增大看最大承受能力）
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 8.219.110.232 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: nginx/1.25.2
Server Hostname: 8.219.110.232
Server Port: 9900

Document Path: /
Document Length: 615 bytes

Concurrency Level: 100
Time taken for tests: 101.462 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 8480000 bytes
HTML transferred: 6150000 bytes
Requests per second: 98.56 [#/sec] (mean)
Time per request: 1014.620 [ms] (mean)
Time per request: 10.146 [ms] (mean, across all concurrent requests)
Transfer rate: 81.62 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 238 627 2073.2 271 15375
Processing: 238 282 79.4 270 2783
Waiting: 238 281 77.7 269 2782
Total: 478 909 2074.6 542 16209

Percentage of the requests served within a certain time (ms)
50% 542
66% 557
75% 571
80% 583
90% 699
95% 1535
98% 7576
99% 15587
100% 16209 (longest request)

微服务：micro service 需要使用容器 尽量将某个服务独立出来 在一个容器里跑

1.IaaS
基础设施即服务，Infrastructure as a Service
基础设施： 就是服务器，就是电脑
提供买服务器给其他的客户的服务 --》阿里云、腾讯云、AWS、华为云等

1. PaaS
   平台即服务，Platform-as-a-Service
   把服务器平台作为一种服务提供的商业模式。PaaS实际上是指将软件研发的平台作为一种服务，以SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。
   买平台给别人使用的，平台里有很多的软件
   区块链平台、存储的平台、cdn等

多媒体数据处理平台及服务
Media PaaS --》语言识别、图像识别等 https://www.qiniu.com/
3. SaaS
软件即服务，Software-as-a-Service
软件即服务，应用模式是基于互联网提供软件服务。如daydao是PaaS平台，但是里面提供的HR、CRM、OA等产品服务属于SaaS。
买软件给其他的人使用
4.serverless ---》直接使用人家的容器平台，将自己的程序代码租用别人的容器去运行，云厂商按照使用时长和算力来收费，企业不需要购买服务器了。 server 服务器 less 没有
5.微服务： 微小的服务
微服务（或称微服务架构）是一种云各架构方法，它把一个大的应用程序拆分成一组小的服务，每个服务都是一个单独的、独立部署的进程。这些服务可以使用不同的语言和框架进行开发，并且通过轻量级的通信协议进行交互。

微服务的核心思想是将应用程序的不同功能模块分解成更小的、独立的服务，每个服务都负责特定的业务功能或业务流程。这些服务可以独立地进行开发、部署、扩展和管理，它们之间通过松耦合的方式进行交互和通信。

微服务的优点包括：
易于开发和维护：每个微服务的功能和代码都是独立的，可以由不同的团队进行开发和维护，使得开发更加高效和灵活。
提高了可扩展性：每个微服务都可以独立地进行扩展，只需要对需要扩展的服务进行升级和部署，而不需要对整个应用程序进行重新部署和测试。
提高容错性：当某个服务出现故障时，不会影响其他服务的正常运行，从而提高了系统的可用性和稳定性。
便于持续集成和持续部署：每个微服务都可以独立地进行测试和部署，使得持续集成和持续部署变得更加容易和快速。
然而，微服务架构也带来了一些挑战，例如分布式系统的复杂性、服务间通信的开销、数据一致性的维护等。因此，在采用微服务架构时需要充分考虑这些因素，并进行合理的设计和管理。