Integrated mongodb driver code

[christkv]

Mongoose is a bit slow in comparison with the driver (about 1/2 of the performance) so changed it to use the mongodb driver directly

[bhauer]

Hi @christkv. Thanks for the contribution! Just a heads-up that when we accept this pull request, we'll be converting it to become a new test that we'll name "nodejs-mongodb-raw." We aim for every test that does not include the "raw" suffix to use an ORM of some flavor.

We have some other tests that do not use an ORM, but rather their platform's native connectivity, such as "php-raw" and "servlet-raw." This additional raw test will be a great comparison data point.

[christkv]

sounds good :)

On Apr 8, 2013, at 3:57 PM, bhauer notifications@github.com wrote:

Hi @christkv. Thanks for the contribution! Just a heads-up that when we accept this pull request, we'll be converting it to become a new test that we'll name "nodejs-mongodb-raw." We aim for every test that does not include the "raw" suffix to use an ORM of some flavor.

We have some other tests that do not use an ORM, but rather their platform's native connectivity, such as "php-raw" and "servlet-raw." This additional raw test will be a great comparison data point.

—
Reply to this email directly or view it on GitHub.

[pfalls1]

@christkv Thanks! Like @bhauer mentioned, I kept the original mongoose test, and now your test will show up as nodejs-mongodb-raw on our results.

[bhauer]

Hi again @christkv. Would you and @bjornstar mind taking a look at issue #33 raised by @sidorares? He points out that since the queries are intended to be independent, we should either:

• Remove the async and simply run the statements sequentially.
• Use a separate connection for each statement that we are presently running using async.

Running async statements on the same connection yields a sequential run of the statements anyway because each connection can process only one statement at a time internally.

Note: In the JVM space, at high client concurrency within our tests (128 or 256), the value of server-side concurrency fan-out vanishes. We're already saturating the cores of the server's CPU at that level of client-side concurrency. Nevertheless, as I understand it, it is idiomatic in node.js to use async for scenarios such as running a bunch of independent queries as we are. I don't have a preference between the two above options; I would rather defer to folks with more node.js expertise.

[bjornstar]

I don't see what's wrong with using async as a control flow library to collect the results of all the database queries. All of these tests are using connection pooling so it should be as parallel as it can get.

Also thanks @christkv for doing the raw version 😸

[sidorares]

@bjornstar - no, it's not parallel, at least in nodejs-mysql-raw example. Each request gets connection from pool (which is ok) and then performs N queries on that connection sequentially. They are not run in parallel despite async.parallel(queryFunctions) - it's a limitation of mysql protocol and mysql client internally queues requests. To actually have them in parallel queryFunction have to acquire connection from pool on each call.

[bjornstar]

I see what you're getting at. You want to have a connection for each request. Go for it. I don't think async is getting in the way of that.

[sidorares]

See #125