Live data from Hacker News

The architecture of Stack Overflow [video]

dev-metal.com

31–40 of 49 posts

Re: The architecture of Stack Overflow [video]

#31

He mentioned that they use the servicestack.text library. I've looked into servicestack recently (using the nuget packages), but then found the library to be pay-to-play. There's an older version (v3) that is BSD licensed that is being maintained. Do any of you have experience with it? I have grown tired of Microsoft pushing new solutions to the same problem (REST service with WCF and then Asp.net web api).

We used it at the time I gave that talk, we don't anymore. We only used JSON serialization and we have rolled out our own free solution, Jil. https://github.com/kevin-montrose/Jil

Technically we use Newtonsoft and Jil, Jil replacing Newtonsoft as we become increasingly confident in it.

I wouldn't suggest anyone use Jil in a production role unless you're at Stack Overflow. It's too untested at the moment, and the typical person can't get me on the horn to fix whatever just broke.

Re: The architecture of Stack Overflow [video]

#32

is there an open source, self-hosted version of stack overflow that you can deploy on your own domain?

Yes. http://meta.stackoverflow.com/questions/2267/stack-overflow-...

To be clear: there is no version of the actual Stack Overflow code that is publicly available. There are, however, numerous open-source reimplementations of portions of the site code.

Also (as the video perhaps mentioned), the Stack Overflow developers have often been able to spin off pieces of the code as open-source libraries. See http://blog.stackoverflow.com/2012/02/stack-exchange-open-so...

Re: The architecture of Stack Overflow [video]

#34

Earlier quoted context omitted.

If most of your classes are small, I don't see why people have to resort to static methods. If your methods are static, there are tendency/lust to use static member variables (hence stateful) which will cause side effects. Don't forget the following points too: 1) You still have pooled objects somewhere (stateless business logic classes like XYZServices, repository classes that may be backed by pooled DB connections…

Small classes are actually worse GC-wise. Because they will fill up the GC graph with many small nodes as opposed to fewer large nodes, which are released in bulk with little fragmentation. Small and large nodes have the same GC overhead essentially. In general you want your objects to be large. When they are small, once the GC realizes what's going on (usually at some high threshold 90% or so), it will have to run a…

Object lifetime is a much more important factor than class size for most server request / response style processing.

Typically there are three lifetimes for objects in server processes. Those that are allocated around startup and are never deallocated; those that are allocated per-request and become garbage once the response goes out; and lifetimes that span multiple requests, like objects in caches.

The first are normally ultra-cheap to "collect": with a generational GC, you simply don't scan them at all, because they haven't changed.

The second group, per-request, are also fairly cheap to collect. Every so often, you GC the youngest generation, and you only need to keep track of references in registers and on the stack. Ideally many requests will have occurred between collections, and the only objects that get kept alive are objects that are in-flight for the current request. And this is why you need at least three generations; you really don't want to have to scan the oldest generation to collect these ephemeral objects after they've built up over a number of youngest generation collections.

It's the third group that kills you. You can save on the cost of scanning the whole heap, using write barriers to track new roots buried in the oldest generation; but that adds accounting costs, and eventually overtakes the cost of a whole heap GC. These guys can also cause the fragmentation you're worried about - they need to be compacted down, copied possibly multiple times. On the CLR, last time I checked, you need a full gen2 GC in order to get rid of them, as they've likely survived a gen1 collection.

With these guys, it's worthwhile doing the big object thing. In fact, it may be worthwhile not having any GC heap storage for them at all, and refer to them using different techniques, like ephemeral keys that look up in Redis, or native pointers stored in statically allocated arrays.

In app servers I've designed, I've never seen GC CPU usage over 5% or so, even with heavy usage of tiny short-lived objects. But you need to care about lifetime.

Re: The architecture of Stack Overflow [video]

#36

The most important thing, technically, is having great developers who ship. For piths sake, I want to say "Everything else is noise" but that isn't true. Everything else can help or hurt, depending on the application and how doctrinaire the application of a given approach/methodology is, the organizational knock on effects (e.g. "Mr Tough Guy Testalot" holds up the release train or nukes your architecture to make it…

Everything else is noise. If you have great developers who ship, then by definition you don't have doctrinaire methodology or "Mr Tough Guy Testalot" (I generally find "Mr No Test" to be a much bigger problem anyway). You might the situation where you have great devs but bad management, but that's next to impossible in the real world.

There's really only two steps to great software development.

1. Hire good developers.

2. Don't hire bad developers

Re: The architecture of Stack Overflow [video]

#37

Earlier quoted context omitted.

We used it at the time I gave that talk, we don't anymore. We only used JSON serialization and we have rolled out our own free solution, Jil. https://github.com/kevin-montrose/Jil

Technically we use Newtonsoft and Jil, Jil replacing Newtonsoft as we become increasingly confident in it. I wouldn't suggest anyone use Jil in a production role unless you're at Stack Overflow. It's too untested at the moment, and the typical person can't get me on the horn to fix whatever just broke.

Why would I use Jil over Newtosoft ?

Re: The architecture of Stack Overflow [video]

#38
post #37

Earlier quoted context omitted.

Technically we use Newtonsoft and Jil, Jil replacing Newtonsoft as we become increasingly confident in it. I wouldn't suggest anyone use Jil in a production role unless you're at Stack Overflow. It's too untested at the moment, and the typical person can't get me on the horn to fix whatever just broke.

Why would I use Jil over Newtosoft ?

You wouldn't right now (Kevin doesn't recommend it). But in the end it you'll want to use it if JSON serialization is a performance bottleneck for you.

Re: The architecture of Stack Overflow [video]

#39

Earlier quoted context omitted.

> StackOverflow employees work from home. Many do, but they have a fairly large office in NYC and a smaller one in London.

The Stack Overflow Q&A dev team has 2 people in New York, out of a team of 10 team. The Careers dev team is more New York heavy, 3 remote and 5 in New York. The sysadmin team is also quite remote, though I don't know the breakdown offhand. I believe at this point most new technical hires are remote. Our offices are mostly sales, Denver and London exclusively so.

I saw that Jason went remote recently. Any particular reason so many devs are going remote? Is it people making individual decisions or the company providing new incentives to do so? My impression when you were at 55 was that most devs worked at the office (I've been at Fog Creek since a little before you guys moved. Hi!).

Re: The architecture of Stack Overflow [video]

#40

Earlier quoted context omitted.

The Stack Overflow Q&A dev team has 2 people in New York, out of a team of 10 team. The Careers dev team is more New York heavy, 3 remote and 5 in New York. The sysadmin team is also quite remote, though I don't know the breakdown offhand. I believe at this point most new technical hires are remote. Our offices are mostly sales, Denver and London exclusively so.

I saw that Jason went remote recently. Any particular reason so many devs are going remote? Is it people making individual decisions or the company providing new incentives to do so? My impression when you were at 55 was that most devs worked at the office (I've been at Fog Creek since a little before you guys moved. Hi!).

The most common reason for someone going remote (that I'm aware of) is starting a family. New York's great, but spacious it is not.

I can think of 3 devs who have gone remote, and 2 devs (including myself) who have moved to NYC since I've been here. Most people stay wherever they were hired. The only location-specific policy I'm aware of is a cost-of-living adjustment in NYC (though that may also apply to London/SF/etc., I don't honestly know).

Post reply on HN