跳到主要内容

性能调优

一、概述 ​

在TUS性能测试时，需要对TUS、数据库、服务器等进行参数调整，以达到程序的最优性能。

​

二、测试环境 ​

本调优在1000M网络连接中进行。硬件和软件环境见下表

名称操作系统cpu类型部署内容cpu/内存/磁盘
管理中心Linux7.9X86_64TUS管理中心和运行时232C/64G/620G
数据库Linux7.9X86_64Kingbase916C/62G/500G
运行时1Linux7.9X86_64负载均衡和运行时132C/64G/620G
压测服务器Linux7.9X86_64Jmeter16C/32G/500G
后端模拟程序Linux7.9X86_64模拟程序16C/32G/500G

拓扑如下图所示，图中红色服务器代表由物理机10.10.92.48虚拟出，蓝色服务器代表由物理机10.10.92.27虚拟出。

topo

三、数据库性能调优 ​

Kingbase9 msyql模式数据库作为TUS的配置库时，配置文件kingbase.conf中关键参数配置如下

max_connections = 300

shared_buffers = 1024MB

tcp_keepalives_idle = 300

tcp_keepalives_interval = 30

work_mem = 256MB

maintenance_work_mem = 1024MB

四、负载均衡性能调优 ​

（一）服务器 ​

负载均衡服务器上，扩大端口号范围。命令如下

echo 1024 65000 > /proc/sys/net/ipv4/ip_local_port_range

（二）httpserver.conf文件​

worker_processes auto;

##工作进程数

worker_connections 65535;

##最大连接数

（三）i-default-cluster.conf文件​

在upstream中加入 keepalive 512;

upstream httpproxyi-default-cluster {
    server 10.10.93.35:19602 max_fails=3 fail_timeout=30s weight=1;
    server 10.10.93.60:19602 max_fails=3 fail_timeout=30s weight=1;
    keepalive 512;
}

.....

upstream gwHttpi-default-cluster { 
   server 10.10.93.35:19210  max_fails=3 fail_timeout=30s; 
   server 10.10.93.60:19210  max_fails=3 fail_timeout=30s; 
   keepalive  512; 

}

（四）启用绑定CPU​

启动负载均衡管理器的管理端，在THS/bin 目录执行

./startConsole.sh

登录负载均衡管理器的管理端（http://IP:8000/）

默认账号： admin

默认密码：Ths#123.com

登录后启用绑定CPU

ths

五、API集成运行时调优 ​

服务器输入ulimit -n 查看文件打开数，若小于10240需要修改文件打开数

（一）临时修改​

执行 ：ulimit -n 10240

临时修改仅对当前会话生效，重新登录服务器后此配置失效。

（二）永久修改​

编辑 /etc/security/limits.conf

在下方添加

  • soft nofile 10240
  • hard nofile 10240

保存文件修改后重启服务器生效。

六、ESB运行时调优​

修改TUS/Server/ESBServer/config/external-linux.vmoptions中内存参数

-Xms8g

-Xmx8g

七、集成流程调优​

为指定流程配置独立的线程池，是实现精细化性能调优、保障系统稳定性的重要手段。您可以在 “运维中心 > 运行管理 > 流程运行管理 > 设置” 页面中，为单个流程进行此项设置。

set

应用场景：​

隔离慢速流程，保障高性能流程响应​

适用类型：入栈端点为REST API(同步)、SOAP API 的流程，以及数据服务中的 数据库、SOAP服务。​
问题描述​

系统中不同流程的执行效率往往存在差异。例如，流程 A 响应迅速，而流程 B 处理耗时。默认情况下，所有流程共享同一个全局线程池。在高并发场景下，流程 B 的长时间请求会占用并耗尽线程池资源，导致流程 A 等其他高性能流程无法及时获取线程，响应延迟急剧增加，甚至引发服务雪崩。

解决方案​

通过为流程 B 配置一个独立的线程池，可以实现资源隔离。

  • 效果：流程 B 的所有请求将消耗其专用线程池的资源，不再影响全局。
  • 优势：全局线程池资源得以释放，确保流程 A 等核心业务的性能和不受慢速流程的干扰。