4 ms·

I must say I'm surprised a Java application could handle 2.5M emails/day (29/second) in less than 1 GB of RAM.

brianwawok 8y ago
Why? Would it surprise you to learn that many of the worlds financial markets run on a handful of Java servers? Message rates of thousands of messages per server is not uncommon. Java is very fast. Very weird people in 2018 think it is not.
- tonyarkles 8y ago
  I think one of the reasons people are startled by the RAM usage figures here is that a Spring Boot app with a bunch of extra jars/"starters" added to it idles at ~500-600MB without any load at all. And can take 30-60 seconds from "java -jar..." to being able to successfully handle its first inbound HTTP request.
  - brianwawok 8y ago
    Well, idle memory usage is not a super useful metric to measure for an app that uses a GC. And in fact the comment was about speed... speed and memory usage can often have inverse relations (think caches) Startup time is not super useful when using a framework with 200,000 lines of code. Try creating a webserver using Java + a servlet, you will be serving requests in < .5 seconds on a modern machine...
    - tonyarkles 8y ago
      Oh, don't get me wrong, I totally agree. You can definitely create lean & mean stuff in Java, it just doesn't seem to generally be the Culture of Java. And while idle memory usage isn't an amazing metric, it's still pretty indicative of bloat. For us, in the current state of things, memory usage is what determines our cloud costs. Setting heap maximums and things seems to somewhat work, although the Spring apps with a max heap set to 512MB still seem to be able to overrun their cgroup max memory of 1GB. There's the new experimental options to have the JVM look at its cgroup limits and manage memory based on that, but due to reasons we don't have a new enough JVM yet. For me and my tastes, Go's pretty tough to beat in the overall productivity/efficiency/reliability set of tradeoffs. I fully admit that that's a taste thing. It's not even that it's amazing at any particular thing, it's actually not really that amazing at all. It just doesn't have anything that particularly annoys me. And the community is awesome: they really don't do the 200kloc framework stuff; the attitude is generally "why do you need all that?" and I agree.
dTal 8y ago
Conversely, I'd say that if you can manage to use over a gigabyte of memory to handle a couple of megabytes per second of traffic, you're probably doing it horribly wrong.

Why? Would it surprise you to learn that many of the worlds financial markets run on a handful of Java servers? Message rates of thousands of messages per server is not uncommon. Java is very fast. Very weird people in 2018 think it is not.

tonyarkles 8y ago
I think one of the reasons people are startled by the RAM usage figures here is that a Spring Boot app with a bunch of extra jars/"starters" added to it idles at ~500-600MB without any load at all. And can take 30-60 seconds from "java -jar..." to being able to successfully handle its first inbound HTTP request.
- brianwawok 8y ago
  Well, idle memory usage is not a super useful metric to measure for an app that uses a GC. And in fact the comment was about speed... speed and memory usage can often have inverse relations (think caches) Startup time is not super useful when using a framework with 200,000 lines of code. Try creating a webserver using Java + a servlet, you will be serving requests in < .5 seconds on a modern machine...
  - tonyarkles 8y ago
    Oh, don't get me wrong, I totally agree. You can definitely create lean & mean stuff in Java, it just doesn't seem to generally be the Culture of Java. And while idle memory usage isn't an amazing metric, it's still pretty indicative of bloat. For us, in the current state of things, memory usage is what determines our cloud costs. Setting heap maximums and things seems to somewhat work, although the Spring apps with a max heap set to 512MB still seem to be able to overrun their cgroup max memory of 1GB. There's the new experimental options to have the JVM look at its cgroup limits and manage memory based on that, but due to reasons we don't have a new enough JVM yet. For me and my tastes, Go's pretty tough to beat in the overall productivity/efficiency/reliability set of tradeoffs. I fully admit that that's a taste thing. It's not even that it's amazing at any particular thing, it's actually not really that amazing at all. It just doesn't have anything that particularly annoys me. And the community is awesome: they really don't do the 200kloc framework stuff; the attitude is generally "why do you need all that?" and I agree.

dTal 8y ago

Conversely, I'd say that if you can manage to use over a gigabyte of memory to handle a couple of megabytes per second of traffic, you're probably doing it horribly wrong.