During installation you specified the user who owns the system. Try running cstop as that user.

You should check for disk speed and latency especially under heavy load. HS should be given a separate disk(s). Hyper-converged infrastructure like you describe can invite performance lags in unexpected ways.

Calling @Mark Bolinsky.

Generalize.

1. You can have 1 BP/1 BO called GET resource which gets:

  • resource id
  • resource type

And based on that information constructs the required JSON.

2. If BP only proxies requests to BO you can skip BP and call BO straight from BS.

Check out RESTForms2 - it does something similar (CRUD over classes) and there's only 4 handlers for all classes. 

While I do agree, what's the use case?

If you're requesting objects en masse it's usually via sql and it's easy to provide id there.

In a case of a singular object you usually request it by ID so it's known beforehand.

Interesting question!
Here are my findings for store/intersystems/irishealth-community:2020.4.0.524.0 and a simple app in the USER namespace.

Uncompressed (Mb) Compressed (Mb)
IRIS 3 323 897
IRIS Squashed 3 293 893
App 8 436 1 953
App MSB 3 526 937
App Squashed 3 576 931
App MSB + Squashed 3 363 904

Notes:

  • MSB means Multi Stage Build
  • Squashed means that an image was built with a --squash option
  • Uncompressed size is calculated via docker inspect -f "{{ .Size }}" $image
  • Compressed size is calculated via (docker manifest inspect $image | ConvertFrom-Json).layers | Measure-Object -Property size -Sum
  • More info on calculating image sizes is available here

Conclusion: either MSB or Squashed work fine, but just MSB would be better for storage as it can have shared layers (squash always produces one unique layer). Squashed is easier to implement.

The best place to do that is your REST broker.

After you got your error from BP, just create your own error and pass that.