This message was deleted.

I think that’s for simplicity of deployment/management

yes, but after debugging the puppetserver GC killing pcp-broker: the overhead of a second JVM would probably be fine 😄

yea it’s all tradeoffs, I can’t speak to the specifics since I haven’t looked very far into it. I can say I haven’t seen any issues of them being co-located but it’s all going to depend

yep. in most environments I've seen it works fine. But if the puppetserver causes issues, it gets really tricky to debug

oh interesting, would be a good place for GC1 garbage collector if that’s the case

ha!

Any changes in average compile times after switching over to G1?

no

👍

ah well. I know nothing got worse in the dashboard. and heap size went down a tiny bit. I dont remember if compilation time got better. I can check that tomorrow

Yeah, my main concern with G1 a lower throughput % (ratio of CPU time spent on application vs. garbage collector) resulting in longer catalog compilation times.

I recall G1 being like a 10% reduction in throughput

That does make a good point about separate JVMs though: Catalog compilation needs a high throughput GC and PCP Broker needs a low pause GC --- and those are opposing goals that a given GC algorithm has to pick one of.

yep I had the same idea. hence the question why those two are even vendored

Yeah. It's mainly a logistical optimization: easier to slot the pcp-broker sub-service into an existing service than to stand up a new package build for it.

mhm okay

And you do save on a few hundred MB of off-heap JVM overhead and potentially wasted space from two separate heaps.

I guess having a pcp-broker package piblicly available would highly increase adoption rate for FOSS users, question is if Puppet/Perforce wants that

The broker is already publicly available: https://github.com/puppetlabs/pcp-broker So, having pre-built packages wouldn't be a huge change. But, the missing FOSS component would be an Orchestrator equivalent that transforms API requests like "run puppet", "run a task", "run a job" into the PXP messages that flow back and forth over the broker.

ah isnt the orchestrator public as well?

No, the Orchestrator service is private.

ah okay

I think they’re combined because it seemed like the obviously correct choice at the time (one process vs. two, lower JVM memory overhead, pcp-broker is small enough it can just slot right in), but it might be something worth reconsidering.