Hacker News Reader

Comment by jm4 | Hacker News Reader

I don't think the author is exactly unnecessarily bashing MongoDB, but MongoDB is not the problem here. It is only part of the story because that's what the author chose to use. I would think that under these circumstances and time constraints, any solution the author might have come up with would have failed.

The bottom line is there were only 4 days to go from idea to supporting 30k concurrent users. That is a recipe for disaster. There are so many things to consider and implement in addition to the software. Nevermind the fact that there were probably laughable requirements for this project and no time allocated to design and testing. There wasn't even sufficient hardware to support the application. This project was a failure almost from the moment it was conceived. This guy never even had a chance.

There is a story in here, but it is not so much about MongoDB.

View on HN

That is what I got from the article. MongoDB may have issues, but:

1. Being expected to develop a fully working, robust application that accepts 30k users in 4 days

2. Agreeing to this commitment

I think are the big failures. Who in their right mind would agree to something like this, even going as far as taking responsibility for it?!

True, when it comes to it, your boss is your boss, fine - if your hand is being forced, do it under protest, rather than pretending this isn't a terrible idea.

as i have said in the disclaimer, i'm definitely not bashing or blaming mongodb for anything. when you read it, you will see that i have done a 30K/sec load testing. the url it was pointed at was doing writes to mongodb. it opened every connection, wrote to the db and closed the connection. this is a huge success for mongodb. the problem is, when you send every single read query to mongodb under a heavy load, within a few seconds, it will just accept connections and will not respond to queries. this is definitely not the case for writing. writing handles them very well. i really would like to know how we screwed there.

I don't know enough about MongoDB to answer your question, and it sounds like you didn't know enough about it to even consider putting it into production for this project. That's where you got screwed. Trying out new technology when you have a likely impossible deadline and then having it fall over in miserable fashion for everyone to see is a good way to get fired. At that point, the debate is not over the ridiculous constraints placed upon you, but rather over the decisions you made.

http://www.mongodb.org/display/DOCS/Connections

That page says each connection spawns a thread. That could be a good lead. The documentation suggests using a connection pool (although many drivers will do this automatically). Were you using one?

http://stackoverflow.com/questions/8439639/mongodb-max-conne...

That StackOverflow question is about supporting 20k concurrent users.

It could also be a matter of insufficient hardware. I don't know, but I would start looking at what kind of performance can be expected in different setups and go from there. The most important thing is to properly test your setup. Prepare for a process of trial and error and expect it to take some time.

You opened a new connection for every request? Shouldn't you have just 1 connection with all the queries going through that connection.

Reply on news.ycombinator.com