Use of MongoDB stored procedures and performance tuning scenarios

This is a creation in Article, where the information may have evolved or changed.

The use of MongoDB stored procedures and performance tuning scenarios.

Auth:philo

A blog in 2012 saw a performance problem

Although MongoDB has given us a lot of drivers to use, but none of the MongoDB shell comes in handy.
For example, the recent need to do dbref nested types of data to do crud would be cumbersome if used with MOG drivers.
So we're going to do an experiment here, first test add the initialization data to the database, add Server-side script
and testing

MONGO adding data

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Db.people.insert ({"_id":"Test","Phone","233333"}) // Enter raw data //Database modification function the modified data is returned after the//update. peopleupdate=function(id,phone){ db.people.update ({ "_id": ID, },{$set: { Phone:phone }}); return db.people.findOne ({"_id": id}); } //Add database Functions Db.system.js.insert ({"_id":"Peopleupdatephone","value": Peopleupdate}); //Modify database functions db.system.js.update ({"_id":"Peopleupdatephone"},{$set: {"value": Peopleupdate}}) //Execute database functions db.eval ("peopleupdatephone (' Test ', ' 23333test ')")

After testing, it is OK in the MONGO shell.

Golang calls the function and returns

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Package Main Import ( "Labix.org/v2/mgo" "Labix.org/v2/mgo/bson" ) Func Main () { session, Err: = MgO. Dial ("") if err! = Nil { Panic (Err) } defer session. Close () session. SetMode (MgO.) monotonic, true) DB: = Session. DB ("Test") var result interface{} db. Run (Bson. m{"eval": "peopleupdatephone (' Test ', ' new test ');"},&result) }

As shown in the code above, you can perform the modification.
But pay attention to the lock problem: eval generates a write lock. As a result you know.

Performance testing.

I directly tested the call to the main function 10,000 times

1. Eval
   1. The eval did not perform well in the test because it would lock the library.
   2. By the way, it's really quite large to have a slot for MongoDB's lock.
   3. Finally test me every time I wait for a result, even a few times to change it takes 4 seconds. (Because the previous lock did not open.) ）
2. RunCommand
   1. It's going to be a lot faster
   2. 2w times Update the same key operation is probably 3s.

Summarize

1. I'm using the MBP MGX82.
2. Although the performance is not very good (with MySQL or a lot worse) but also enough to support the general application
3. Not MongoDB not violence, just because I do not understand it.