Mongodb performance on Windows

Question

I've been researching nosql options available for .NET lately and MongoDB is emerging as a clear winner in terms of availability and support, so tonight I decided to give it a go. I downloaded version 1.2.4 (Windows x64 binary) from the mongodb site and ran it with the following options:

C:\mongodb\bin>mkdir data
C:\mongodb\bin>mongod -dbpath ./data --cpu --quiet

I then loaded up the latest mongodb-csharp driver from http://github.com/samus/mongodb-csharp and immediately ran the benchmark program. Having heard about how "amazingly fast" MongoDB is, I was rather shocked at the poor benchmark performance.

Starting Tests
encode (small).........................................320000 00:00:00.0156250
encode (medium)........................................80000 00:00:00.0625000
encode (large).........................................1818 00:00:02.7500000
decode (small).........................................320000 00:00:00.0156250
decode (medium)........................................160000 00:00:00.0312500
decode (large).........................................2370 00:00:02.1093750
insert (small, no index)...............................2176 00:00:02.2968750
insert (medium, no index)..............................2269 00:00:02.2031250
insert (large, no index)...............................778 00:00:06.4218750
insert (small, indexed)................................2051 00:00:02.4375000
insert (medium, indexed)...............................2133 00:00:02.3437500
insert (large, indexed)................................835 00:00:05.9843750
batch insert (small, no index).........................53333 00:00:00.0937500
batch insert (medium, no index)........................26666 00:00:00.1875000
batch insert (large, no index).........................1114 00:00:04.4843750
find_one (small, no index).............................350 00:00:14.2812500
find_one (medium, no index)............................204 00:00:24.4687500
find_one (large, no index).............................135 00:00:37.0156250
find_one (small, indexed)..............................352 00:00:14.1718750
find_one (medium, indexed).............................184 00:00:27.0937500
find_one (large, indexed)..............................128 00:00:38.9062500
find (small, no index).................................516 00:00:09.6718750
find (medium, no index)................................316 00:00:15.7812500
find (large, no index).................................216 00:00:23.0468750
find (small, indexed)..................................532 00:00:09.3906250
find (medium, indexed).................................346 00:00:14.4375000
find (large, indexed)..................................212 00:00:23.5468750
find range (small, indexed)............................440 00:00:11.3593750
find range (medium, indexed)...........................294 00:00:16.9531250
find range (large, indexed)............................199 00:00:25.0625000
Press any key to continue...

For starters, I can get better non-batch insert performance from SQL Server Express. What really struck me, however, was the slow performance of the find_nnnn queries. Why is retrieving data from MongoDB so slow? What am I missing?

Edit: This was all on the local machine, no network latency or anything. MongoDB's CPU usage ran at about 75% the entire time the test was running. Also, I ran a trace on the benchmark program and confirmed that 50% of the CPU time spent was waiting for MongoDB to return data, so it's not a performance issue with the C# driver.

Answer 1

This is atypical. How much RAM do you have on that box? What does top show as the tests are running? On my laptop I can easily get numbers much higher than this w/o the actual mongod process even breaking a sweat.

Answer 2

I did run that benchmark too. That piece of code has a lot of bugs. The creation of the index for instance fails but the exception is swallowed so the search is still slow.

But also be aware that the large object has a lot of "detail objects". It is a hierarchy, not a single record. One document has 280 detail 'records'. It is unfair to compare such large document with one row from an rdbms table like sql server.