5 ms·

In-memory, in-process storage is by far the fastest option (assuming you know a hashtable from a granola bar). A single server can easily handle 1000+ requests/

by andr 19y ago

In-memory, in-process storage is by far the fastest option (assuming you know a hashtable from a granola bar). A single server can easily handle 1000+ requests/second, which is plenty. The only reason not to do it is if your data doesn't fit in RAM, which is probably not the case for News.YC.

boucher 19y ago
This is a scaling question. Clearly the question is, assuming the current set up is no longer enough, what would be the best way to scale this architecture.
- rshao 19y ago
  Probably the easiest would be to use memcache for some of the repeated queries, specifically the items that are relatively static, such as the original post or posted item details. It probably wouldn't help too much on the front page, since that'll update constantly and therefore just be a waste of overhead.
  - boucher 19y ago
    This doesn't really address the issue that there's no centralized information repository. With the content entirely in RAM, to distribute the app to two boxes would require either some sort of message broadcasting system, or re-architecting the data to be stored in some other way.
drm237 19y ago
Agreed that in-memory storage is by far the fastest form of storage available to a single server setup like this. However, I was thinking hypothetically if load was the issue, how would people scale the backend. I was curious if one option would emerge as a favorite. I disagree that the only reason not to do it is if the data won't fit in RAM. Going to a multi-server setup has many advantages including redundancy for situations such as these, of course, at the cost of increased administration.
- mrtron 19y ago
  These sort of questions have resulted in the traditional web setup you see today with a database backend for storage. Any reasonably large site will (relatively) quickly exhaust RAM, especially if the same server is handling the requests. Plus, traditionally there are large sets of data that needs to be searchable, hence the desirability of putting it in a database. So instead of actually having things in memory, people now use something like memcache to reasonably simulate that for performance.

by andr 19y ago

boucher 19y ago

This is a scaling question. Clearly the question is, assuming the current set up is no longer enough, what would be the best way to scale this architecture.

rshao 19y ago
Probably the easiest would be to use memcache for some of the repeated queries, specifically the items that are relatively static, such as the original post or posted item details. It probably wouldn't help too much on the front page, since that'll update constantly and therefore just be a waste of overhead.
- boucher 19y ago
  This doesn't really address the issue that there's no centralized information repository. With the content entirely in RAM, to distribute the app to two boxes would require either some sort of message broadcasting system, or re-architecting the data to be stored in some other way.

drm237 19y ago

Agreed that in-memory storage is by far the fastest form of storage available to a single server setup like this. However, I was thinking hypothetically if load was the issue, how would people scale the backend. I was curious if one option would emerge as a favorite. I disagree that the only reason not to do it is if the data won't fit in RAM. Going to a multi-server setup has many advantages including redundancy for situations such as these, of course, at the cost of increased administration.

mrtron 19y ago
These sort of questions have resulted in the traditional web setup you see today with a database backend for storage. Any reasonably large site will (relatively) quickly exhaust RAM, especially if the same server is handling the requests. Plus, traditionally there are large sets of data that needs to be searchable, hence the desirability of putting it in a database. So instead of actually having things in memory, people now use something like memcache to reasonably simulate that for performance.