baseline for time to sync stacks blockchain

[wileyj]

document expected sync time as of Feb 15 2022 (48915 blocks) using a $20/mo DO droplet.

[wileyj]

@whoabuddy

[whoabuddy]

Just over 2 hours have passed and I'm past the first 1,000 STX blocks, will continue to track and post again once fully synced.

== Timestamp
2022-02-15 09:18:47
== Hiro API
{
  "burn_block_height": 723463,
  "stacks_tip_height": 48912
}
== Freehold API
{
  "burn_block_height": 666076,
  "stacks_tip_height": 11
}

== Timestamp
2022-02-15 11:40:16
== Hiro API
{
  "burn_block_height": 723480,
  "stacks_tip_height": 48927
}
== Freehold API
{
  "burn_block_height": 667428,
  "stacks_tip_height": 1047
}

So far performance metrics are well within spec, too, using ~50% CPU as it continues to sync (6 hour view).

[whoabuddy]

Update: 56 hours in and everything is still working as expected, past halfway caught up to the chain

== Timestamp
2022-02-17 17:10:55 (~56 hours)
== Hiro API
{
  "burn_block_height": 723821,
  "stacks_tip_height": 49228
}
== Freehold API
{
  "burn_block_height": 695037,
  "stacks_tip_height": 25194
}

Performance metrics are looking good as well (7 day view).

[whoabuddy]

Node is fully synced and working well so far!

Start: 2022-02-15 09:18:47 End: 2022-02-22 22:37:52

According to timeanddate.com that's 7 days, 13 hours, 19 minutes and 5 seconds.

Follow-up test this morning:

== Timestamp
2022-02-23 05:53:36
== Hiro API
{
  "burn_block_height": 724607,
  "stacks_tip_height": 49918
}
== Freehold API
{
  "burn_block_height": 724607,
  "stacks_tip_height": 49918
}

Performance metrics over a 14 day window. The most recent activity on the right is me running scripts against the node, but I have no idea what the spike was between 2/21 and 2/22.

[wileyj]

hmm, not ideal - but good to know it's possible to run on a small VM. I suspect the bottleneck here is Memory - are those metrics exposed in the DO dashboard?

[whoabuddy]

Wow sorry I missed that comment. With this configuration, no, I'd have to add the new metrics and didn't take that step on this build. Ref: https://docs.digitalocean.com/products/monitoring/how-to/switch-agents/

It's allocated 4GB memory, 80GB Disk (basic), and 2 vCPUs - so far performance has been steady, here is a 14-day view from the console:

And this was the plan I used:

[wileyj]

with some recent updates, i've launched a new instance using updated repo code and the recent 2.05.0.2.0 release. so far, it's moving along fairly quickly using the same droplet size:

}root@stacks-blockchain-2:/opt/stacks-blockchain-docker# curl localhost -sL
{
  "server_version": "stacks-blockchain-api v3.0.3 (master:cd0c8aef)",
  "status": "ready",
  "chain_tip": {
    "block_height": 17119,
    "block_hash": "0x5522a5c3ac5db8343868e11ca01ed819b1a93e064afc99cd0e10ccbdfb987b2a",
    "index_block_hash": "0x49c6338f511db98c179d7a7a609f0838fd3ae34ccae9a24def9f29cea7df2e16"
  }
}root@stacks-blockchain-2:/opt/stacks-blockchain-docker# uptime
 23:13:39 up 21:25,  1 user,  load average: 1.72, 1.78, 1.80

this image has also been submitted for review as a 1-click droplet, so we'll see in 2-3 days.

For reference, this image enables BNS, and both fungible/non-fungible metadata in the API. outside of stacks-blockchain version and stacks-blockchain-docker updates, nothing else is changed.