search

bmino / binance-triangle-arbitrage

Detect in-market cryptocurrency arbitrage
MIT License
1.07k stars 336 forks source link

Is there any advantage of having multiple CPUs on the server? #96

Closed mizzdev closed 4 years ago

mizzdev commented 4 years ago

Hi there!

Currently I'm running the arbitrage bot on a VPS with 3 CPUs, which are recognized according to the performance log:

However, it seems that only one of the CPUs out of three is efficiently loaded having the rest of them idle:

Here is what top output shows:

I am aware that Node.js operates in a single thread when it comes to execution of user code while managing the thread pools for variouts I/O (e.g. HTTP requests, Websocket handling, FS, database connection, etc.).

The questions are:

  1. Should I worry about having a single CPU overloaded and potential lags due to that?
  2. Is there any advantage of running the app on a machine with multiple CPUs rather than a single CPU?
  3. Have you got looking into experimental Worker threads feature in your future plans? In theory, it may help balancing the load among multiple CPUs or CPU cores. An alternative may be usage of cluster module, which, in fact, based on idea of child processes communicating with master process via IPC. What are your considerations?

Huge thanks in advance!

mizzdev commented 4 years ago

Well, it seems that my DigitalOcean metric collection system has been lying since scaling the VPS from 1 vCPU to 3vCPU plan:

As you can see, it fact all 3 CPUs are around 20% loaded. False alarm :)

Anyway, question 3 is what I'm still curious about hence I won't hurry to close this issue.

bmino commented 4 years ago

Hey! Thanks for your interest in the project!

Awhile back this project actually did use worker threads and configured them to be scaled with the number of CPU cores available. The problem that I ran into was the overhead in passing information to/from worker threads wasn't worth the gain in speed.

For further discussion the worker threads were assigned to do calculations for each "cycle" ie: every 250ms a cycle is initiated where the app iterates through all possible arbitrage positions and calculates expected profit on each. This calculation was farmed out to worker threads and performed asynchronously in a pool.

I never experimented with a cluster. In theory you could split the workload between between 2 apps right now with no need for clustering where each app runs on it's own core. You would need to divide the total number of possible arbitrage pairings in half and assign whitelists/blacklists to force each app to only scan a subset of the market.

mizzdev commented 4 years ago

Thanks for detailed response!

I never experimented with a cluster. In theory you could split the workload between between 2 apps right now with no need for clustering where each app runs on it's own core. You would need to divide the total number of possible arbitrage pairings in half and assign whitelists/blacklists to force each app to only scan a subset of the market.

I think I'll give it a try once I get some actual trades executed and collect some statistics. One of the viable approaches may be to dockerize the app and manipulate config.json through container start parameters or image build parameters in some way, thus there will be no need to alter the actual source code to support configuration switching. Anyway, that's a little bit outside of the current discussion.

Cheers!