4 ms·

I have a question for experts in Hoodie and/or other similar projects (like Meteor): How are database connections managed? If every client (browser) basically

I have a question for experts in Hoodie and/or other similar projects (like Meteor): How are database connections managed? If every client (browser) basically talks nearly directly to the database, don't you end up with of thousands of database connections? Large number of connections is not a problem by itself, and servers like nginx handle them well, but I am not aware of a database which will feel comfortable being exposed this way. MongoDB, for example, really starts struggling with 2K+ connections. PostgreSQL can barely handle a hundred. Is this why CouchDB is used? Is connection pooling used on the server? Or maybe the connections are short-lived and never persistent? Basically, how does this work with large number (say, 10K) of concurrent visitors? Thanks!

janl 14y ago
As long as the underlying OS can provide file descriptors, CouchDB can handle the concurrent connections through the magic of Erlang, both persistent and shorter lived. There are obvious limits to this, but the Hoodie architecture allows easy scale out (more DB servers and manual sharding, or a dynamo-like BigCouch, more workers etc.) that we’ll get to making use of once Hoodie apps become that big.
- tarabukka 14y ago
  Magic of Erlang? I hate to be cynical, but have you got benchmarks to back that up?
  - janl 14y ago
    Yeah.
- OGC 14y ago
  To rephrase the other question: So what "magic" does Erlang do then? How does it work?
  - janl 14y ago
    tl;dr: keeping sockets open only uses very little memory and no CPU when idle. dr: http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-doe... ff.