-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Surprisingly high time spent in Ntp._now
#49
Comments
Thanks for reporting this @radekmie. I looked into optimizing Are you able to check which functions were calling Ntp._now during the time it was spending a lot of time? Maybe we can find a way to reduce how often it is called. |
Small update: enabling |
We can simplify |
We are facing the same problem. _now is the dominant leaf in our cpu profiles We have redis-oplog actually enabled cc @radekmie |
Hi there! In apps with a relatively high number of published documents, the time spent in
Ntp._now
function is surprisingly high:I've checked the source and I believe the
Date.now()
alone is not the cheapest buttypeof
is just making it worse. I understand where are those mitigations coming from, but maybe they could be done once? Or even through a configuration?And to be clear: it happens only when a huge amount of oplog changes hits the server - otherwise, it's lower (but still clearly visible):
Let me know if you'd need more info from my side!
The text was updated successfully, but these errors were encountered: