db性能优化

一、py脚本释放cpu资源，time.sleep(0.001)

python脚本释放cpu资源，time.sleep(0.001)

1. 原来写了个time.sleep(0.02)。为什么这么写的原因有点不太确定了，回忆了下，大概是一开始是轮询模式，避免tick触发太频繁，所以每20ms判断1次。后面改为阻塞模式，没有去掉这个time.sleep(0.2)。导致执行命令时，总有20多ms的耗时。
2. 内网是20个服的db布置在同一台物理机上，每个服16条线程，一共300多条线程。如果time.sleep(0.001)很容易就能把cpu干爆（100%）。并且有的线程一直持有cpu，有的线程一直抢不到cpu资源。就会发现有的人访问db很快，有的人访问db就很慢。
3. 2023-09-28 后来发现，前面的结论不完全准确。time.sleep(0.001)已经交出cpu时间片了。原则上运行的dbpy的cpu使用率应该很低。实际上没有业务的时候，确实只占用2~3%的使用率。但是内网有17个db布置在同一台机器上。db数量 * 服务数量 * cpu使用率= 17*2*2.5 = 85，也就是空转的时候，已经吃掉了85%的cpu。内网是双核的机器，相当于有200%cpu，85/200=0.425，差不多就是mobaXterm显示的值。
4. 2023-09-28 这里犯了一个很傻逼的错误，不断的调整sleep的时长。其实并没有什么意思。sleep(0.001)已经交出cpu时间片了。如果cpu使用率还很高的话，那么说明业务逻辑占用了太高的cpu。需要去优化业务逻辑，调整sleep并没有实际解决问题。
   把sleep从0.02修改为0.001，cpu使用率当然会下降。那是因为业务逻辑函数被触发的次数下降了。但是要维持tps的话，业务逻辑函数不能下降调用次数。

import time
def Work():
	a = 1
    while a < 0xFFFF:
    #while a < 0xFFFFFF:
        a += 1

def Main():
	Work()
	time.sleep(0.02)
	#time.sleep(0.1)

二、time.sleep()精度问题

在windows中，time.sleep(0.001)并不能实现让线程睡眠1毫秒，因为操作系统的精度问题，其睡眠时长大概在16ms左右。得使用time.perf_counter()函数。

lastTime = time.perf_counter()
while True:
	nowTime = time.perf_counter()
	if nowTime - lastTime >= 0.001:
		# 执行函数
		Func)()
		lastTime = time.perf_counter()

精度问题2

time.perf_counter()这个函数好像也不太好用。换了一种思路去解决。
用py写了一个测试脚本，在循环里面insert log到mysql，大概每秒能插入8000条log。但是在storage_py里，每秒只能处理100条左右，差了整整80倍。

1. 后来排查，发现生产线程从redis队列中取请求req的速度就很慢，1秒钟就只blpop出100个左右。最后判断是time.sleep(0.001)使用不恰当，这里以为1秒能取出1000个请求。但由于time.sleep(0.001)实际上睡眠16ms左右，所以取出的请求数量大概是1000/16=62。
   解决方案是：sleep一次以后，加个计数一直blpop取，取够200个命令，才进入下一次sleep。
   2023-09-28：订正一下，这里为啥要加计数呢？计数其实并不合适。这里应该直接用阻塞，当请求队列中有请求的时候，应该一直取，知道队列取完了，那么退出业务逻辑。执行1次sleep(0.001)。嗯这样改完以后，速度提升显著。

2. 同样的，在消费线程处理req的时候，发现也是16ms才处理一条，王德发。于是也改成，sleep一次以后，就处理够200个，才进入下次sleep。(2023-09-28 注：这里也改成阻塞了)

三、insert数据有点慢，表的主键、索引、自动递增

1. insert数据有点慢，表的主键、索引、自动递增
   插入战报、log的操作有点慢。

四、 dbsdk读取resp有点慢，因为互斥锁lock太多代码了

dbsdk读取resp有点慢，因为互斥锁lock太多代码了

1. 锁越多的代码，锁住的时间就越久。其它线程等待的时间也越长。所以在实现功能的情况下，锁越少的代码越好。
2. 双缓存队列，只在交换的时候，锁一下，其它时候，2个线程只访问当前持有的队列。

五、关闭auto commit

mysql的auto commit是默认是打开的
pymysql多次execute()，一次commit()
定义了个遍历，每累计执行execute()1000个命令，就commit()提交1次。

1. 提升蛮多的，但是要注意如果在commit之前出错了，要捕获异常，在处理异常中，执行commit()，否则会出现命令未提交的现象。
2. 遇到个问题，有些命令是需要立即写数据库的。比如创建角色，在insert插入角色之后，会从数据库select查询角色数据。此时因为还没有累计达到1000个命令，所以数据库里并没有角色数据。没有角色数据，就被认定为新角色。这样上层逻辑就不对了。用数量来控制是否commit()会有问题
换了种方法，记录上次提交的时间戳，用时间来控制是否commit()，测试下来目前好像没什么问题。
   解决方案：数量控制+时间控制。

log类的request命令，可以用合并提交的方式来优化。

六、不设置cb回调函数

game内存容易增长，因为所有命令都要等python执行完毕，然后才释放内存。但有一些命令，可以不需要回调，因为回调也不会做什么操作。例如：log命令、操作缓存类的命令。

七、其它

• __forceinline加在模板函数前，声明为内联模板函数。
• 尽量避免字符串的构造和析构。比如参数要求string，传递参数本身已经是string，不要再使用str.c_str()。