Skip to content
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

add: refactor backtesting to a different fork #281

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

juandelacruz-calvo
Copy link
Contributor

This commit updates backtesting to be executed in a different fork, it allows to start up several different executions independently, either by different tabs or even different pairs at the same time.

In the future, this process could be persisted in database with the intention of running long backtestings of years of information on several dozen pairs.

The exclusive locking had to be disabled so that each fork also has access to transact with the database. It would be interesting to move it to a Postgres, including a potential docker file

This commit updates backtesting to be executed in a different fork, it allows to start up several different executions independently, either by different tabs or even different pairs at the same time.

In the future, this process could be persisted in database with the intention of running long backtestings of years of information on several dozen pairs.

The exclusive locking had to be disabled so that each fork also has access to transact with the database. It would be interesting to move it to a Postgres, including a potential docker file
pairs.forEach(pair => {
backtestPendingPairs[key].push(pair);

const forked = fork('src/command/backtest.js');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just call the code directly instead of forking.
"LOCKING_MODE = EXCLUSIVE" is needed for performance reason.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you call the code directly it doesn't benefit from parallel execution for various pairs at the same time, right? Also, the UI was struggling when a backtest was configured for various thousand hours

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it should have some sort of lock or limiter, if this is not handled carefully it may induce too much load onto the server and cause a heap overflow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'm completely unaware of that, I'll dig a bit into it to see if I can figure out how to implement it neatly, thanks!

Copy link

@Wladastic Wladastic Jan 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can setup a queue that consists out of an array holding each job.
That would be easiest, to just pop each job after the prior got done.
Main benefit of the array would be that the jobs just die away once you kill the server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants