Load metrics are hard - how can you know exactly how many commands your worker can handle, or how many entities? Depending on what exactly you’re doing, an entity may be very cheap to be authoritative over, or very expensive.
Ultimately it’s down to your application and logic.
The examples in the docs use a simple queue of tasks with a size limit, but you’d have to know the profile of the code, and the limits of a single process to set that limit intelligently.
Using a time-based metric attempts to ignore all that difficulty. If you spent 500ms of the last 1 second processing stuff, you’re probably at 50% load.
However, that’s only a reasonable approximation if your worker is single-threaded, and CPU-bound. If you’re multithreaded, or would run out of memory before CPU time, maybe time spent processing isn’t a good metric.
UnityWorkers (aka FSims before v10) are different as they have a target framerate, so each frame has a time ‘budget’. If the event loop uses half the budgeted time, that’s 50% load.
You can actually take a look and see in Assets\Improbable\Sdk\Src\Unity\Metrics\UnityFixedFrameLoadMetricProvider.cs
re: a -sources
jar, that sounds interesting, but maybe worth a new topic to explain why 