Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Netflix uses Java

infoq.com

Post reply on HN
Print view View original

31–40 of 205 posts

Re: How Netflix uses Java

#31

Post by Cthulhu_ »

inparen wrote: post #17

Spring Boot and Spring cloud for backend & graphql for the win. ;-)

Spring is a safe and reliable choice I'd say; not the most exciting, but neither code nor frameworks should be exciting, they're used to solve a problem, they shouldn't become the problem itself.

GraphQL is interesting to me, I thought the clients were pretty similar across all platforms, meaning their API usage should also be similar enough to not need the flexible nature of GraphQL. But then, it allows for a lot more flexibility and decoupling - if a client needs an extra field, the API contract does not need to be updated, and not all clients need to be updated at once. Not all clients will be updated either, they will need to support 5-10+ year old clients that haven't updated yet for whichever reason.

Re: How Netflix uses Java

#32

Post by Cthulhu_ »

oldnet wrote: post #27
stanac wrote: post #25

Earlier quoted context omitted.

How is java being used on server side affecting your client?

It's constantly sending requests from BE to FE - checking IP, checking watch time etc.

That shouldn't take that much CPU tbh, but if it does, it sounds like they have some optimization to do.

I wonder if it's like DRM in video games, causing a lot of overhead.

Re: How Netflix uses Java

#33

Post by dustingetz »

jarym wrote: post #3

Interesting the article jumps straight from REST to GraphQL and forgets Falcor[0] - Netflix's alternative vision for federated services. For a while it looked like it might be a contender to GraphQL but it never really seemed to take off despite being simpler to adopt. [0] https://netflix.github.io/falcor/

iirc falcor predated graphql

Re: How Netflix uses Java

#35

Post by robertlagrant »

Cthulhu_ wrote: post #31
inparen wrote: post #17

Spring Boot and Spring cloud for backend & graphql for the win. ;-)

Spring is a safe and reliable choice I'd say; not the most exciting, but neither code nor frameworks should be exciting, they're used to solve a problem, they shouldn't become the problem itself. GraphQL is interesting to me, I thought the clients were pretty similar across all platforms, meaning their API usage should also be similar enough to not need the flexible nature of GraphQL. But then, it allows for a lot mo…

Well, if the field is not available then new backend code will need to be written, resolvers, integrations, etc. But it does allow UIs to take less info over the wire, and eitherfewer joins need to be done or fewer performance-oriented APIs need building, as you say.

Re: How Netflix uses Java

#37

Post by CraigJPerry »

Macha wrote: post #12
ValtteriL wrote: post #4

>Netflix observed a 20% increase of CPU usage on JDK 17 compared to JDK 8. This was mostly due to the improvements in the G1 garbage collector. Help me here, why do GC improvements cause CPU increase?

A somewhat common problem is to be limited by the throughput of CPU heavy tasks while the OS reports lower than expected CPU usage. A lot of companies/teams just kind of handwave it away as "hyperthreading is weird", and allocate more machines. Actual causes might be poor cache usage causing programs to wait on data to be loaded from memory, which depending on the CPU metrics you use, may not show as CPU busy time. F…

>> while the OS reports lower than expected CPU usage

>> which depending on the CPU metrics you use, may not show as CPU busy time

If your userspace process is waiting on memory (be that cache, or RAM) then you’ll show as CPU busy when you look in top or whatever - even though if you look under the covers such as via perf counters, you’ll see a lack of instructions executed.

The CPU is busy in this case and the OS won’t context switch to another task, your stalled process will be treated as running by the OS. At the hardware thread level then it will hopefully use the opportunity to run another thread thanks to hyper threading but at the OS level your process will show user space cpu bound. You’ll have to look at perf counters to see what’s actually happening.

>> you might end up with 20 servers at 50% usage, but using 10 servers will take twice as long but still appear to be at 50% usage.

Queue theory is fascinating, the latency change when dropping to half the servers may not be just a doubling. It depends on queue arrival rate and processing time but the results can be wild, like 10x worse.

Re: How Netflix uses Java

#38

Post by HeckFeck »

Cthulhu_ wrote: post #32
oldnet wrote: post #27

Earlier quoted context omitted.

It's constantly sending requests from BE to FE - checking IP, checking watch time etc.

That shouldn't take that much CPU tbh, but if it does, it sounds like they have some optimization to do. I wonder if it's like DRM in video games, causing a lot of overhead.

Makes sense. The most gifted coders wouldn't work in DRM and telemetry. At least I hope that's what is happening.

Re: How Netflix uses Java

#39

Post by williamdclt »

oldnet wrote: post #27
stanac wrote: post #25

Earlier quoted context omitted.

How is java being used on server side affecting your client?

It's constantly sending requests from BE to FE - checking IP, checking watch time etc.

That’s entirely unrelated to the backend language (and mostly unrelated to CPU usage for that matter).

Re: How Netflix uses Java

#40

Post by RamblingCTO »

inparen wrote: post #17

Spring Boot and Spring cloud for backend & graphql for the win. ;-)

No, just no. Performance and debugging are just plain horrible. The spring team loves to force you into their automagic shit and this bean stuff is so annoying. You almost got no compile time safety in this stack. It's the bane of my existence. I'd like to know that a compiled program will run. That seems virtually impossible with java/spring boot.
Post reply on HN