Stack traces can provide useful diagnostics when something goes wrong, but can also incur high overhead when everything is going right. Stack traces are always captured for exceptions, but can also be enabled for routine actions like queries and ViewContext creation. Such traces can be helpful in tracking down memory leaks or ResultSet closure, but impose a performance hit. By default, stack traces for routine/non-exception actions are not captured, but you can enable them for the current server session if needed for troubleshooting. To enable non-exception stack trace capture:
To review stack traces captured via this mechanism, you can use the MiniProfiler, or view them in the Queries diagnostics interface from the admin console.
When Tomcat is restarted or the web app is redeployed, this setting will revert to the default and only capture stack traces for exceptions.
Developers can add new tracking code for stack traces by using "MiniProfiler.getTroubleshootingStackTrace()". This function will return NULL if tracing is disabled and a trimmed version of the trace if it is enabled.
The MiniProfiler tracks the duration of requests and any queries executed during the request. It is available on servers running in dev mode or for platform developers in production mode. Site administrators also have access to the profiler whenever it is enabled.
When enabled, the profiler adds a little widget to one corner of the page. For every page render or AJAX request, a button showing the elapsed time the request took is added to the profiler. Clicking on the time will bring up some summary details about the request.
Duplicate queries will be highlighted.
Clicking on the link in the sql column will bring up the queries page showing each query that was executed, it's duration, and if enabled, a stack trace showing where the query originated.
| previousnext |
| expand allcollapse all |
