Hacker News Reader

Comment by thraxil | Hacker News Reader

>> Since these components are doing different things, there is little chance that there would be a performance benefit

> Complementary workloads should not be a problem. It would actually make thrifty usage of the hardware.

The argument continued "there is little chance that there would be a performance benefit from being in the same JVM". Splitting the two components out into separate containers doesn't preclude running them on the same hardware. But it does give you the option of running them on separate hardware, which may allow for even more efficient overall hardware usage.

View on HN

Splitting into separate JVMs two services that communicate through a Java interface would also add lose you:

* the L1, L2, L3 cache friendliness

* the inlinings that JITs can provide

* the temp variable eliminations that JITs can provide

* the ability to do zero copies

You would add:

* the overhead of the full http stack, if this is done in REST

* the network latency, if this is on separate hardware

If you care about latency, just forget splitting it. Worst cases could be going from nanoseconds to milliseconds.

If you care about throughput, it could help in offloading; but don't expect 2 to be split into 2 x 1. You would be closer to 2 x 1.5.

AWS is supposed to give us soon some new shiny X1 instance types. Before scaling forces you to split, there is plenty of room for pretty beefy monoliths with 2TB of ram and 100 vCPUs.

The article in the next point though says "These two applications communicate using a REST API (…instead of using sockets, shared memory or files, etc.)."

So it's already lost all the benefits that it could have from running both components in the same JVM and communicating via a Java interface.

> the overhead of the full http stack, if this is done in REST

Yeah, just don't do this.

The only performance reason I could imagine would be if both pieces had required large heaps and had difference garbage collection profiles. Putting them in separate containers (and by extension JVMs) would split the size of the heap for garbage collection and provide more deterministic garbage collection cycle times. However, to receive such a benefit, the heaps would need to be fairly large (e.g. greater than 4GB each).

> (e.g. greater than 4GB each).

That's an awful lot of RAM to be using. I doubt many people even have servers with that amount of RAM in them let alone enough for 2.

Have you seen a modern server? People have 1TB Ram in some of them.

I've seen 2TB already.

I thought that I didn't need to explicitly tag that as sarcasm. Apparently I was wrong...

the jvm is already a container, putting them in docker is additional overhead vs simply starting two java processes.

Reply on news.ycombinator.com