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

Best practices can slow your application down

stackoverflow.blog

Post reply on HN
Print view View original

141–150 of 187 posts

Re: Best practices can slow your application down

#141

Post by 908B64B197 »

orclev wrote: post #124
arcturus17 wrote: post #69

Earlier quoted context omitted.

I also found the "or similar practices that the industry seems to love" coming across as a bit vague and even arrogant. On the other hand, I think that they have earned bragging rights - we're talking about a site that has massive scale and reach, and has a reputation for being a very efficient system. I appreciate that people like them share their views, even if they are contrarian and a touch arrogant. > they chose…

It's important to remember Joel Spolsky, one of the founders of stackoverflow is an old school Microsoft guy that managed the Excel team before starting his own company. He has always been a bit of a Microsoft fanboy, and used to advocate a lot for VB as a serious language back before it got swallowed by .Net and turned into a less powerful syntax for C#. The fact they chose C# isn't surprising at all given that. It…

> it's the fact that they picked a language that at the time really only ran on Windows, and as a consequence they were forced into running their web servers on Windows.

If the founders and early employees were from Microsoft it might have been easier for them to use Windows Server since they were already pretty well versed in Windows development.

It's a pattern I constantly see: "Why did your startup use X instead of Y?"

"Ohh well X has this feature that Y lacks and so and so... ohh and the founder and his friend were pretty good at X and used it before."

Re: Best practices can slow your application down

#142

Post by datavirtue »

arcturus17 wrote: post #127
orclev wrote: post #124

Earlier quoted context omitted.

It's important to remember Joel Spolsky, one of the founders of stackoverflow is an old school Microsoft guy that managed the Excel team before starting his own company. He has always been a bit of a Microsoft fanboy, and used to advocate a lot for VB as a serious language back before it got swallowed by .Net and turned into a less powerful syntax for C#. The fact they chose C# isn't surprising at all given that. It…

Yea they mention that in the post. I agree with you that it seems like a self-imposed limitation. At the same time, it makes one think how said limitations can actually foster creativity and efficiency. They mention in the post - they constantly gloat about this - that they could run SO on one or two machines. I'd imagine that said machine would need to be a behemoth and not a t3.micro, but intuitively I feel that th…

They were/are on bare metal so they have real dedicated cores and no VM overhead. Two bare metal cores is a hell of a lot faster than two virtual cores. I had been away from infrastructure during the rise of vmWare and didn't realize that the core count was potentially fake. I was sparring with an admin over resources one day and mentioned the number of cores on the VM and he just laughed. "Those are virtual, you don't really have four cores." Be careful in your assumptions about these VMs in the cloud.

Re: Best practices can slow your application down

#143

Post by ed_elliott_asc »

helsinkiandrew wrote: post #101
Cthulhu_ wrote: post #89

Earlier quoted context omitted.

They're really not selling their codebase or practices to me to be honest. If their system is built like that it might have enough performance to run a top x site on only a handful of bare metal servers, but the article also implies there's a lot of "here be dragons" code - don't touch this, you are not clever enough to test this, and since we don't have tests, you might break it by touching it. Which is just bad pra…

> the article also implies there's a lot of "here be dragons" code Agreed, fine if enough of the core developers are around, but if the company merged, the app needed to be extended or altered significantly, or some of the underlying technology stack is deprecated/becomes unsupported keeping things working will be very expensive.

I think that they are in the situation where it can't be altered significantly which ironically is probably a good thing for stack overflow - they don't have reams of features.

Re: Best practices can slow your application down

#144

Post by petercooper »

pbowyer wrote: post #61
acd wrote: post #20

Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

I like RDS because I don't have to think about backups, replication etc but if I colocate the app server (web server, application code) and the database server on the same machine I see 1-2 orders of magnitude performance improvement in database-intensive apps. Replication is the same as usual; have another machine setup to replicate onto. The restriction is you can't fan out hundreds of application servers and half…

I like RDS for the same reason, but I wonder if there's a way you could run Postgres locally, as you suggest, while still using RDS for all the replication/backup side of things? That way the local Postgres management could be pretty minimal and outsource the "annoying bits" to RDS as before. I need to look into the best way to set up something like that.. perhaps pgPool-II.

Re: Best practices can slow your application down

#145

Post by scott00 »

I don't understand the claim that replacing "polymorphism and dependency injection" with "static fields and service locators" reduces allocations.

I would expect that getting rid of dependency injection would allow you to convert a virtual method call to a direct method call, and replace a constructor argument with a static field reference, but I don't see the connection to allocation.

Anybody understand this?

Re: Best practices can slow your application down

#146

Post by dustinmoris »

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

100% agreed. This was a very poor article.

They've basically gone with an overly expensive Microsoft stack which meant that from the beginning they were fighting the wrong fight. Instead of thinking about scale for best performance, they had to think about best cost for minimum scale.

Furthermore they decided to bastardise their C# code to some fake low level untestable C dragon code which makes matters even worse. They have created a huge mess which is probably extremely hard to maintain and too precious to touch for a performance gain which probably still only scratches on the surface of what a true low level language could have achieved.

The best practice would have been to build the parts which matter most in a language which allows them to be blazingly fast and write nice testable and easy to understand code. Something like Rust or Go. But no, they stuck with C# for god knows what reason (maybe financial Microsoft incentives who knows?) and had to throw away every sensible coding practise in order to make it work.

This is literally a blog post describing how not to run a large scale website.

Re: Best practices can slow your application down

#147

Post by orclev »

arcturus17 wrote: post #132
bluGill wrote: post #126

Earlier quoted context omitted.

> It sounds like they would've lost a lot of the conveniences that a framework like .net gave them. Would they have? It sounds like they put a lot of effort into bypassing the garbage collector by creating buffers up front and then never letting then reusing them so they can never be garbage collected. Best practice in embedded C code is to allocate buffers up front and then reuse them. The terminology in the above t…

> I don't know enough about .net to answer the question - even if I did the answer probably depending on if you are doing something where .net has a saner syntax, or run of the mill code that looks almost identical in C++ as .net I don't know enough about either C#/.net or C++ - I was merely speculating. I know there are some web frameworks for C++, but I've never heard of any big websites being built with them. I am…

Pretty sure Amazons entire backend is C++. Hard to get much bigger than that.

Re: Best practices can slow your application down

#148

Post by hinkley »

azeirah wrote: post #15
hinkley wrote: post #6

Earlier quoted context omitted.

Very, very few people know how to make cheap tests. I have one guy who writes fixtures that couples all of his tests. When I need to add functionality, first I have to replace his fixtures with basic stubs, just so I can add another bit of functionality. And we have two people who copy his coding style. Probably to fit in. I think, based on my own experiences and working with people learning to write tests, that 'sim…

I never got to understand testing. It's a thing that every developer is supposed to know and do well somehow. I always end up writing tests for my programs, but with all the stubs and fixtures and weird stuff I get into hairy problems that I don't understand. Tests are supposed to be helpful, but writing good tests is ridiculously hard. Or maybe it's just because I'm a perfectionist, and I should be happy with crappy…

I kept telling people for years that I'm awful at writing tests. You're coming to me for advice because I'm less awful than you are.

Nobody really seemed to get what I was trying to tell them. It parallels my experiences with Scrum "Well if it's not working you're doing it wrong". I love tests, and I hate tests. It's a very codependent relationship.

I did run into a string of people who had either very good value statements or very good questions, which helped.

But I still find tests I've written that violate the guidelines I try to set for the team. There are probably few moments in the week when I have, to be completely blunt, my head so far up my own ass as when I'm writing tests. The only time I am juggling more info at once is when I'm debugging, and in debugging I don't have to worry about the future reader. I doubt I am unique in either regard.

Unless I go out of my way to make the tests as agonizingly boring as I possibly can.

Re: Best practices can slow your application down

#149

Post by hinkley »

beny23 wrote: post #13
hinkley wrote: post #6

Earlier quoted context omitted.

Very, very few people know how to make cheap tests. I have one guy who writes fixtures that couples all of his tests. When I need to add functionality, first I have to replace his fixtures with basic stubs, just so I can add another bit of functionality. And we have two people who copy his coding style. Probably to fit in. I think, based on my own experiences and working with people learning to write tests, that 'sim…

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microse…

> Good tests enable refactoring.

I don't disagree. So when I do find tests that inhibit refactoring, what do you suppose I infer about those tests?

Re: Best practices can slow your application down

#150

Post by hinkley »

CraigJPerry wrote: post #26
beny23 wrote: post #13

Earlier quoted context omitted.

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microse…

>> If the tests are too complex for anyone to change the code, the the code is too complex In enterprise software, the pattern i see is specifically coupling rather than garden variety complexity. There’s a really pervasive idea that unit testing means 1:1 mapping of test class to production code class. To put it another way, there’s this really common but terrible idea that tests should map to your current implement…

> To put it another way, there’s this really common but terrible idea that tests should map to your current implementation rather than the behaviour you want.

I think if you were prioritizing, then the most bang for the buck comes from making your white box tests as stupid-simple as you possibly can. Since those demand a particular implementation.

Post reply on HN