PR #138 - A Couple of Useful Knobs for Hive-Engine Nodes

Hey everyone,

I have been spending some time in the Hive-Engine node codebase, looking at a larger list of possible performance and lite-node improvements.

I decided not to start with the flashy stuff.

The first pass is a small feature branch with two operator settings that were previously hardcoded in the node.

The short version is:

Hive-Engine nodes can now configure the JavaScript VM limit and MongoDB connection pool settings without changing the existing defaults.

Why Start Here?

The original improvement proposal had a lot of ideas in it: caching, faster syncing, smarter cleanup, snapshots, RPC changes, and more.

Those may all be worth investigating, but this is a nine-year-old consensus codebase. The cost of a change is not just the time it takes to write the code.

It is also the time it takes for somebody else to convince themselves that the change is safe.

So I wanted the contribution to be small, easy to explain, and easy to turn off.

Nothing changes unless an operator chooses to add the new settings.

What Changed

The first setting is maxJSVMs.

Hive-Engine runs smart contracts inside isolated JavaScript virtual machines. The node had a hardcoded maximum of five VM instances. That is now configurable:

{
  "maxJSVMs": 5
}

The default remains five. Missing or invalid values fall back to five as well.

The second setting is databasePool:

{
  "databasePool": {
    "maxPoolSize": 20,
    "minPoolSize": 2,
    "maxIdleTimeMS": 30000,
    "waitQueueTimeoutMS": 10000
  }
}

This lets an operator tune the MongoDB connection pool for the kind of node they are running.

A witness node may want to keep things smaller. A public RPC node handling more concurrent requests may benefit from a larger pool.

Again, if databasePool is omitted, the MongoDB driver's existing defaults remain in place.

Documentation Matters Too

The README now describes the available options, their defaults, and the general difference between tuning for a witness and tuning for an RPC node.

Configuration without explanation tends to become folklore. I would rather leave a short note behind than make the next operator read the implementation to understand what a number means.

Where It Is Now

The work is on my personal branch and PR #138 is open to the qa branch:

feature/bundle-a-config-knobs

The commit is 0ad6355.

No benchmark claims yet. No promise that changing a pool size will magically make a node faster. Just two useful operator knobs, documented and safely defaulted.

As always,
Michael Garcia a.k.a. TheCrazyGM