[SERVER-64241] Speedup timeseries_expire.js test Created: 07/Mar/22  Updated: 29/Oct/23  Resolved: 30/Mar/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Yujin Kang Park
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2022-04-04
Participants:

 Description   

timeseries_expire.js test is by far the slowest test on our jscore suite. It runs for around 1 min and 40 secs.

The reason is very simple... the test waits two times for expire documents on the timeseries collection to be deleted. Those documents are deleted by the TTL monitor that by default gets executed every 60 s.

In order to speedup this test we could override the ttlMonitorSleepSecs paramter to a much lower value.



 Comments   
Comment by Githook User [ 30/Mar/22 ]

Author:

{'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}

Message: SERVER-64241: Make ttlMonitorSleepSecs change effective immediately. Speedup timeseries_expire.js
Branch: master
https://github.com/mongodb/mongo/commit/84befbcce9ba114af5c2eef117042b449c2017a8

Comment by Louis Williams [ 07/Mar/22 ]

We could also move this to a no_passthrough suite, since most TTL tests are already there.

Comment by Tommaso Tocci [ 07/Mar/22 ]

I actually tried to use a lower ttlMonitorSleepSecs value in this patch. Unfortunately simply changing the parameter at the beginning of the tests won't be sufficient, because by that time a TTL monitor could have already started waiting and in that case we will wait the default 60 secs regardless.

Another approach would be to set a lower value for the ttlMonitorSleepSecs at the suite level. Considering that this tests is running in several suites, it means that we would need to override this parameter in all those suites.

Generated at Thu Feb 08 05:59:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.