[SERVER-9899] Performance of JavaScript Stored Function on MongoDB Server Created: 11/Jun/13 Updated: 10/Dec/14 Resolved: 25/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript, Performance |
| Affects Version/s: | debugging with submitter |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Abhishek Kumar | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 0 |
| Labels: | javascript, mongodb, performance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux |
||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
This is related to javascript stored function in mongodb server. I know all the details about the working and use cases. I am doubtful about one line which is in the official documentation of MongoDB. "Note : We do not recommend using server-side stored functions if possible." After moving to V8 JavaScript engine ( improving concurrency issues for javascript queries ) and given the fact this may save us many network round trip time, why this is not recommended? Also, if there some performance difference in running javascript queries Vs running normal queries ( given both are able to use index ) ? Please link me to supported documentation. Also, it will be much useful, if the reason for such statements are also mentioned in the documentation. |
| Comments |
| Comment by Andy Schwerin [ 14/Jun/13 ] |
|
It is not a statement about the current implementation, but a statement about what may be in the future. I do not know of any specific reason why performance would differ between a query run in an eval and one run over the network, today. |
| Comment by Abhishek Kumar [ 14/Jun/13 ] |
|
Is it possible to elaborate on this part, may be using some example? |
| Comment by Andy Schwerin [ 14/Jun/13 ] |
|
The two situations may have different locking behavior, but do not necessarily. |
| Comment by Abhishek Kumar [ 14/Jun/13 ] |
|
Just want to confirm what I understood is correct. |
| Comment by Andy Schwerin [ 13/Jun/13 ] |
|
The "nolock" argument to eval causes a more typical database locking behavior to apply. The query execution engine may yield the read lock periodically. As to your last question, I recommend conducting the same experiment again, to convince yourself, but queries without a $where component will not use javascript evaluation to test each document. |
| Comment by Abhishek Kumar [ 12/Jun/13 ] |
|
Thanks for making me understand the difference. I run the test as you told, and clearly seeing the big difference in response time. Please let me know, if eval with nolock option, yields the read lock or not? The documentation is not having this information. |
| Comment by Andy Schwerin [ 11/Jun/13 ] |
|
There will be a performance difference in the two queries that you describe. Both of them will be able to use the {{ {a: 1}}} index, but the form that uses $where to examine the value of b will pay a constant factor overhead for invoking javascript execution on documents that match a. I recommend that you construct a simple collection of a few hundred thousand documents, where a few tens of thousands have {{ {a: 1}}}, and compare performance of the two queries, to get a sense for the amount of overhead. Of course, if the expression you wish to compare is not expressible in the current version of the query language, you may have to use $where form. It is typically worth avoiding, however. |
| Comment by Abhishek Kumar [ 11/Jun/13 ] |
|
@Andy ) ) ) |
| Comment by Andy Schwerin [ 11/Jun/13 ] |
|