[SERVER-7225] Consider replacing/refactoring log() streams. Created: 02/Oct/12 Updated: 02/Oct/12 Resolved: 02/Oct/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | 2.0.7, 2.2.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Ben Becker | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | logging | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
All |
||
| Attachments: |
|
| Participants: |
| Description |
|
Currently, all log messages are implemented using streams and manipulators. This is problematic when a function is passed to a log() stream (because the function will be called regardless of the log level or use of NullStreams). Take, for example, this seemingly innocuous line:
Because mdata is of type ParallelConnectionMetadata, and defines a toString() method which calls toBSON(), we waste CPU time (and malloc/free much more than necessary) even if verbose logging is disabled. To gauge impact, the supplied patch was applied. A simple stress test which floods mongos with simple find() operations performed 6500 queries per second unpatched, and 7600 queries per second with the patch. |
| Comments |
| Comment by Ben Becker [ 02/Oct/12 ] |
|
The LOG() macro already exists to solve this problem by jumping over the stream evaluation entirely if the global log level is less than the supplied argument. Updated documentation to reflect this behavior: https://wiki.10gen.com/display/DOCS/Kernel+logging |