3 ms·

We use s similar setup to what they are using. We use in house built MVC framework though. Our Model is a lacking but still works. We do still use Memcached and

We use s similar setup to what they are using. We use in house built MVC framework though. Our Model is a lacking but still works. We do still use Memcached and I don't see how they can skip that. I don't know what their user numbers are like for even 1-2k concurrents that many Mongo queries could be deadly.

SeoxyS 16y ago
We're still at a very early stage and the traffic is definitely not what it's gonna be in the future yet. So far, Mongo has held up beautifully in real-life situations and benchmarking, and we can deploy new boxes infinitely to beef up our replica set with Amazon EC2 when we reach our limits—but Memcached is not out of the picture entirely. So far there's been no need for it (which would not be the case with MySQL) but if future traffic starts to call for it, we'll definitely add that to our setup.
- plasma 16y ago
  Note that you can only get up to 7 usable members in a RS (then you need to shard), see http://www.mongodb.org/display/DOCS/Replica+Sets+Limits http://www.mongodb.org/display/DOCS/Replica+Sets+Limits I'm curious if you happen to use any monitoring to notice when load on your mongo servers gets too high (eg is about to start swapping to disk instead of using RAM etc)? Cheers
- elliottcarlson 16y ago
  One thing to note in my experience with Mongo vs Memcached for certain tasks. Back in the day we used to use MySQL as a shared session storage for load balanced web servers - this is obviously something from the past and since then we moved it to Memcached. Once we started implementing Mongo, it seemed to make perfect sense to just use Mongo instead of Memcached to store that information - but to my surprise (and I love Mongo), Memcache outperformed Mongo as far as overhead and latency goes for managing the sessions. We now keep all session management in Memcached at all times and Mongo for everything else.

SeoxyS 16y ago

We're still at a very early stage and the traffic is definitely not what it's gonna be in the future yet. So far, Mongo has held up beautifully in real-life situations and benchmarking, and we can deploy new boxes infinitely to beef up our replica set with Amazon EC2 when we reach our limits—but Memcached is not out of the picture entirely. So far there's been no need for it (which would not be the case with MySQL) but if future traffic starts to call for it, we'll definitely add that to our setup.

plasma 16y ago
Note that you can only get up to 7 usable members in a RS (then you need to shard), see http://www.mongodb.org/display/DOCS/Replica+Sets+Limits http://www.mongodb.org/display/DOCS/Replica+Sets+Limits I'm curious if you happen to use any monitoring to notice when load on your mongo servers gets too high (eg is about to start swapping to disk instead of using RAM etc)? Cheers
elliottcarlson 16y ago
One thing to note in my experience with Mongo vs Memcached for certain tasks. Back in the day we used to use MySQL as a shared session storage for load balanced web servers - this is obviously something from the past and since then we moved it to Memcached. Once we started implementing Mongo, it seemed to make perfect sense to just use Mongo instead of Memcached to store that information - but to my surprise (and I love Mongo), Memcache outperformed Mongo as far as overhead and latency goes for managing the sessions. We now keep all session management in Memcached at all times and Mongo for everything else.