3 ms·
The idea is that you coordinate concurrent read/write to the same structures, yielding a shared data view without formal coordination. Also, the structures may
by jdunck 15y ago
The idea is that you coordinate concurrent read/write to the same structures, yielding a shared data view without formal coordination. Also, the structures may be large enough that you don't want them all in-memory for each client.
- nostrademons 15y agoI was kinda assuming that the system already has a separate appserver tier from the webserver tier (HN doesn't, but many other real-world apps would). Separating application logic from HTML formatting is usually a good idea, if only because HTML templating tends to be CPU-intensive but memory-light while application logic is often CPU-light but memory-intensive. That's an orthogonal issue, though - you can run as many appserver instances as are necessary for your dataset. I guess I was wondering why, in your app server, you don't just add a big in-process heap and use the normal language mechanisms to access it wherever you'd return your leaderboard info? The concurrency issue is interesting - how does Redis handle it? Does it have some sort of STM, or is it all because everything executes in a single thread in Redis? If it's the latter, you'd get that for free in a single-threaded appserver (although you probably don't want a single-threaded appserver).
- tabbyjabby 15y agoRedis is single-threaded. Also, not everyone uses stateful app servers.