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

81–90 of 205 posts

Re: How Netflix uses Java

#81

Post by [deleted] »

StevePerkins wrote: post #67
Tainnor wrote: post #62

Earlier quoted context omitted.

I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns. Debugging why something doesn't work in Spring can also be a nightmare. And th…

> "...failures depending on the order of test execution." Every time I've seen issues where the order of test execution matters, it's either been: (1) someone one writing integration tests and calling them unit tests, or (2) transaction management issues with H2 or some other embedded test database. For #1, you're going to have a bad time with any stack. For #2, transaction management with Spring Data JPA is admitted…

[deleted]

Re: How Netflix uses Java

#82

Post by _old_dude_ »

dboreham wrote: post #76
znpy wrote: post #42

Earlier quoted context omitted.

> Help me here, why do GC improvements cause CPU increase? In Java 8 (afaik) there were pretty much no generational or concurrent garbage collectors, so garbage collector would happen in a stop-the-world manner: all work gets put on a halt, garbage collection happens, then the work can resume. If you have a better GC, you have shorter and less frequent needs to do a stop the world pause. Hence the code can run on cpu…

Java8 was at least a decade into generational and concurrent GC. It does STW once in a while though which may be what you meant.

You have two kind of concurrent GCs, the ones where the marking phase in concurrent with the application and the ones where the evacuation phase is also concurrent with the application.

G1 only does the marking concurrently, the evacuation is done in small pauses. A decade ago, there was only one concurrent evacuation GC available in Java, C4 from Azul. Now, we have Shenandoah and ZGC.

Re: How Netflix uses Java

#83

Post by frederikb »

oldnet wrote: post #80
kaba0 wrote: post #71

Earlier quoted context omitted.

You can be harsh — it is pretty dumb to come here shitting on a whole platform, when they don’t even know the basics.

Tell me ... why it's only netflix what makes CPU go on max? Why netflix is giving me info message when I turn on VPN in the middle of movie? Why it's only netflix who stop working another second when my internet connection has quick failure? Sorry but it seems that you have no idea how netflix really works.

The point that the others are trying to make is that these questions are not relevant in the context of the backend technology choices. The REST or GraphQL endpoints could be handled by monkeys writing bits via typewriters and it wouldn't affect the CPU usage in your browser.

Re: How Netflix uses Java

#84

Post by geodel »

throwaway1492 wrote: post #79
geodel wrote: post #78

Earlier quoted context omitted.

"This person" makes rather relevant comment on Spring boot's severe shortcomings. Whereas your comment from throwaway account is blabbering nonsense.

Well that supports my point actually, that these "short comings" aren't short comings at all if one takes the time to learn the framework. Blabbering? People often say that who have no valid technical or intellectual response.

Why would framework be correct if the premise of heavy runtime reflection based approach itself is bad?

You can spend your lifetime learning this framework, others can simply reject on first principles' basis.

Re: How Netflix uses Java

#85

Post by kaba0 »

oldnet wrote: post #80
kaba0 wrote: post #71

Earlier quoted context omitted.

You can be harsh — it is pretty dumb to come here shitting on a whole platform, when they don’t even know the basics.

Tell me ... why it's only netflix what makes CPU go on max? Why netflix is giving me info message when I turn on VPN in the middle of movie? Why it's only netflix who stop working another second when my internet connection has quick failure? Sorry but it seems that you have no idea how netflix really works.

Do you even know what a frontend/client is vs a backend?

The frontend is anything but java (the website uses javascript, they have mobile apps, not sure what they are written in, but besides android having a few necessary wrappers, these are also not java applications).

You don’t see the backend and they do different things between different services so not much point in comparing them - that’s a huge, complex, partially cached-at-your-ISP even network infrastructure.

Besides, Java itself is very fast and is itself no reason for an applications’ (especially network-related) bad performance. It literally runs like half of the internet, with basically every other top 100 IT companies having business-critical infrastructure dependent on it.

Re: How Netflix uses Java

#87

Post by oldnet »

kaba0 wrote: post #85
oldnet wrote: post #80

Earlier quoted context omitted.

Tell me ... why it's only netflix what makes CPU go on max? Why netflix is giving me info message when I turn on VPN in the middle of movie? Why it's only netflix who stop working another second when my internet connection has quick failure? Sorry but it seems that you have no idea how netflix really works.

Do you even know what a frontend/client is vs a backend? The frontend is anything but java (the website uses javascript, they have mobile apps, not sure what they are written in, but besides android having a few necessary wrappers, these are also not java applications). You don’t see the backend and they do different things between different services so not much point in comparing them - that’s a huge, complex, parti…

BE doesn't need constant info about user if BE would be correctly written.

I never saw BE which sends so much requests to FE for user info. Someone just has no idea how to use Java without making CPU wild.

Re: How Netflix uses Java

#88

Post by toast0 »

xorcist wrote: post #59
Macha wrote: post #12

Earlier quoted context omitted.

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…

When you put it like that, yes. Hardware is cheap and all that. In practice I think that an organization that doesn't understand the software it is developing has a people problem. And people problems generally can't be solved with hardware. If somebody knows how to make that insight actionable, let me know. No, hiring new people is not the answer. In all likelihood that swaps one hard problem for an even harder.

IMHO, Usually the people problem is that there are too many people working on the same machine. Sometimes that's unavoidable.

Sometimes, honestly, understanding the software its developing isn't an important business goal. It makes me personally angry, but most businesses do right by not picking business goals to placate me.

Sometimes you just have too many people.

Sometimes you can restructure your software and systems so that fewer people are working on a system and they can understand it better. Sometimes that would also involve restructuring your organization, which has pluses and minuses.

If you can ensure the smaller teams run similar stacks, there can be some good knowledge transfer when one team figures out an underlying truth about the platform that could apply elsewhere. And sometimes you get a platform expert team that can help with understanding and problem solving throughout the teams.

Re: How Netflix uses Java

#89

Post by RamblingCTO »

throwaway1492 wrote: post #79
geodel wrote: post #78

Earlier quoted context omitted.

"This person" makes rather relevant comment on Spring boot's severe shortcomings. Whereas your comment from throwaway account is blabbering nonsense.

Well that supports my point actually, that these "short comings" aren't short comings at all if one takes the time to learn the framework. Blabbering? People often say that who have no valid technical or intellectual response.

I don't see anything beyond ad hominem. That reveals more about yourself than you probably think. I'll move on then.

Re: How Netflix uses Java

#90

Post by RamblingCTO »

Tainnor wrote: post #62
StevePerkins wrote: post #52

Earlier quoted context omitted.

I'm not sure what "no compile time safety in this stack" even means in the context of a strongly-typed compiled language. If you are referring to the dependency injection container making use of reflection, then Spring Native graduated from experimental add-on to part of the core framework some years ago. You can now opt for Quarkus/Micronaut-style static build-time dependency injection, and even AOT compilation to G…

I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns. Debugging why something doesn't work in Spring can also be a nightmare. And th…

> I've never used any other webstack (and I've used several, in several languages) where it was so hard to figure out why different tests pollute each other, causing subtle failures depending on the order of test execution. Sure, you could say that it's all a matter of learning the right way, but there are just a terrible amount of footguns.

> Debugging why something doesn't work in Spring can also be a nightmare.

Making these points you can see if somebody actually used Spring in production ;)

How much time we've lost with caching in tests and other shennanigans. I've never had a stack causing more problems by just being how it is than with Spring Boot. Don't even get me started on the absolute clusterfuck of hibernate. I'd love to move on from anything from this stack and we're working on it! Absolute dumpster fire.

Post reply on HN