关于从节点 延迟的测试:
使用手工设置延迟时间的方法,在两个数据库中测试了主从 写/读的延迟时间,
主从节点的延迟时间大约 在 0.3秒 。
这个测试比我想象中的要大很多,开始以为延迟也就在10 -30 毫秒左右
或许这个测试只能说: ”延迟0.3秒后,能在从节点中查询到所插入的数据比例越大“ 更贴切点。
如果是插入后要即刻返回数据的,暂时只能指定从主节点读取数据。
****************************************************************************************************
测试1: 循环N次,
1. 主节点插入_id=i,
2.设置延迟时间的长短,
3.从节点查询_id=i ,显示插入的时间。
测试库(1主,1从,1仲裁,版本为2.6):
1.不设置延迟的情况下,从节点能查询到数据的 78/1999
2.查询时间向后延迟0.1秒,从节点能查询到数据的 360/499
3.查询时间向后延迟0.2秒,从节点能查询到数据的 449/499
4.查询时间向后延迟0.3秒,从节点能查询到数据的 473/499
另外一套数据库环境 (1主4从,版本为2.6):
1.不设置延迟的情况下,从节点能查询到数据的 45/999
2.查询时间向后延迟0.1秒,从节点能查询到数据的 433/499
3.查询时间向后延迟0.2秒,从节点能查询到数据的 492/499
4.查询时间向后延迟0.3秒,从节点能查询到数据的 498/499
(以上只测试了单条插入情况,如果主节点更新多条记录,从节点的延迟可能会更大,因为多条记录的修改,在从节点是做为多条记录各自处理的)
测试2:考虑到测试1可能存在锁争用问题:在主库循环插入数据后,因为日志是同步同步到从节点,而从节点再重现数据时,可能存在锁问题。
把测试1中的时间延迟0.X 秒,修改为同库其它表插入数据后,再回来查看测试表中的数据是否已同步到从节点。
测试下来看到当其它表数据插入越多(各表插入数据时间消耗只有几毫秒)。从节点数据重现数据越慢。
(测试库中进行测试)
--------------------------------------------------------------------------------------------
测试1 python 脚本:
测试2 脚本:
#time.sleep(0.1) 修改为循环在其它表插入一条数据,当循环越大时,从库数据重现越慢。
for j in range(2,20):
tst_db.get_collection('test%s'%str(j).zfill(2)).insert({"_id":i,"date":datetime.datetime.now()})
使用手工设置延迟时间的方法,在两个数据库中测试了主从 写/读的延迟时间,
主从节点的延迟时间大约 在 0.3秒 。
这个测试比我想象中的要大很多,开始以为延迟也就在10 -30 毫秒左右
或许这个测试只能说: ”延迟0.3秒后,能在从节点中查询到所插入的数据比例越大“ 更贴切点。
如果是插入后要即刻返回数据的,暂时只能指定从主节点读取数据。
****************************************************************************************************
测试1: 循环N次,
1. 主节点插入_id=i,
2.设置延迟时间的长短,
3.从节点查询_id=i ,显示插入的时间。
测试库(1主,1从,1仲裁,版本为2.6):
1.不设置延迟的情况下,从节点能查询到数据的 78/1999
2.查询时间向后延迟0.1秒,从节点能查询到数据的 360/499
3.查询时间向后延迟0.2秒,从节点能查询到数据的 449/499
4.查询时间向后延迟0.3秒,从节点能查询到数据的 473/499
另外一套数据库环境 (1主4从,版本为2.6):
1.不设置延迟的情况下,从节点能查询到数据的 45/999
2.查询时间向后延迟0.1秒,从节点能查询到数据的 433/499
3.查询时间向后延迟0.2秒,从节点能查询到数据的 492/499
4.查询时间向后延迟0.3秒,从节点能查询到数据的 498/499
3.2.3 版本集群环境测试(1p+2s)
1.不设置延迟的情况下,从节点能查询到数据的 281/500
2.查询时间向后延迟0.1秒,从节点能查询到数据的 495/500
3.0以上的版本,性能确实好了很多了。
<span style="font-size:24px;color:#FF6600;"><strong>后面在更单一的环境中重新测试了一把。
(1p+2s+1a,2g 内存的虚拟环境,mongoDB ver:3.2.7 ).延迟只有0.002 sec.</strong></span>
(以上只测试了单条插入情况,如果主节点更新多条记录,从节点的延迟可能会更大,因为多条记录的修改,在从节点是做为多条记录各自处理的)
测试2:考虑到测试1可能存在锁争用问题:在主库循环插入数据后,因为日志是同步同步到从节点,而从节点再重现数据时,可能存在锁问题。
把测试1中的时间延迟0.X 秒,修改为同库其它表插入数据后,再回来查看测试表中的数据是否已同步到从节点。
测试下来看到当其它表数据插入越多(各表插入数据时间消耗只有几毫秒)。从节点数据重现数据越慢。
(测试库中进行测试)
--------------------------------------------------------------------------------------------
测试1 python 脚本:
#primary
tst_conn = pymongo.MongoClient(['mongodb://10.0.0.48:27017'])
tst_db=tst_conn.test
#slave
tst_conn2 = pymongo.MongoClient(['mongodb://10.0.0.67:27017'])
tst_db2 = tst_conn2.test
for i in range(1,500):
#primary insert data
tst_db.test01.insert({"_id":i,"date":datetime.datetime.now()})
print 'i=%d'%i,datetime.datetime.now()
#sleep
time.sleep(0.1)
#slave select data
cur = tst_db2.test01.find({"_id":i})
for row in cur:
print 'select secoundary data: ',row["_id"],row["date"]
测试2 脚本:
#time.sleep(0.1) 修改为循环在其它表插入一条数据,当循环越大时,从库数据重现越慢。
for j in range(2,20):
tst_db.get_collection('test%s'%str(j).zfill(2)).insert({"_id":i,"date":datetime.datetime.now()})