This blog post describes the oft-overlooked browser-based debugger available in the Sitecore ASP.NET CMS, and how you can use it to diagnose performance issues and other problems with Sitecore solutions.
Sitecore includes a browser-based debugger that you can use remotely without installing any software. To access the debugger, log in to the Sitecore desktop, click the Sitecore button, and then click Debug. The browser-based debugger opens in a new browser window or tab. A gray bar at the top of the page contains an icon at the far right to show or hide the debugging ribbon.
By default, the debugger resolves requests to the /configuration/sitecore/sites/site element named website, which uses the web database by default, and to the home item in that database. To add a command to the Content Editor ribbon that debugs the selected item in the content database, see my blog post Add a Button to the Sitecore Content Editor Ribbon to Debug Any Item in Any Database.
On the ribbon in the Sitecore debugger, in the Modes group, you can enable or disable inline editing with the Edit command and switch between the Preview and Debug interfaces.
In the Profile group, you can enable or disable performance profiling, and if profiling is enabled, save or download a performance profile report for the current page. In the Trace group, you can enable or disable Sitecore tracing, and if tracing is enabled, save or download a trace report for the current page. A profile is a high-level summary of the performance of a page; a trace is a low-level description of the steps involved in the page generation process. You can use the profile and trace to identify underperforming components within a page, and underperforming steps within those components.
In the Rendering group, you can enable and disable Borders and Information, the first of which renders borders around presentation components, and the second of which causes Sitecore to render information icons (green triangles) for each presentation component. Hovering over an information icon renders information about that indivual presentation component inline in the page, including its profile, cache settings and output. When the Rendering Information checkbox is selected, Sitecore invokes each presentation component on each page request, never retrieving the output of a presentation component from cache. To debug caching, disable Rendering Information.
In the Open group, you can access the standard ASP.NET Trace, and in the Close group, you can Log Off.
If profiling or tracing is enabled, the profile and/or trace appears at the bottom of the page. The profile attempts to identify hot spots (worst performing components, and components that accessed a large number of items). The profile and trace may contain error messages, such as if layout details indicate to bind a presentation component to a placeholder that does not exist (which otherwise generates no output to the page).
You can use the trace to determine whether Sitecore retrieved the output of each presentation component from cache, or invoked the component anew. If you use XSL renderings, note that Sitecore caches XSL transformation objects as well as the output of XSL transformations.
You can use the trace to determine whether Sitecore retrieved the output of each presentation component from cache, or invoked the component anew. If you use XSL renderings, note that Sitecore caches XSL transformation objects as well as the output of XSL transformations. Messages such as the following appear in the trace when Sitecore uses an entry from the output cache:
Finished rendering "/xsl/sample rendering.xslt" (using cache).
Messages such as the following indicate re-use of an XSL transformation object:
Xslt file loaded from cache.
Except during development, you will typically choose to debug a page after detecting a warning or error in a Sitecore log (such as the dreaded "threshold exceeded" warning), or when a user reports that a page does not work correctly or underperforms. Use the Sitecore debugger to identify the problem component.
In addition to the Sitecore browser-based debugger, you can also use the Visual Studio debugger. In general, use the Sitecore debugger to identify high-level issues, and the Visual Studio debugger to step through low-level code. Attach to the existing w3wp.exe process instead of starting the debugger, and then request a page that triggers a breakpoint or throws an exception. See Debugging Your Sitecore Code on SDN for more information, but attach to w3wp.exe rather than aspnet_wp.exe if needed.
Update 7.September.2011: two additional resources that can help with debugging include the /sitecore/admin/cache.aspx and /sitecore/admin/stats.aspx pages. Some versions of Sitecore deny anonymous access to the /sitecore/admin subdirectory, so you may need to enable anonymous access in IIS in order to use these tools. For more information about these pages, see the Cache Configuration Reference on SDN.
www.experimentsincode.com/ www.experimentsincode.com/ www.experimentsincode.com/
Hello, maybe You can help me to understand why debug mode is not working for me. I trying to debug our company's developed solution to find bottleneck on high load, but when I run debug mode home item is opened and all looks fine. Now when I going to different page, I don't see any debug and trace information, only green arrows, with text, that trace file in /temp/diagnostics doesn't exists. Actually they only created for home item, not for any descendants. We are using Sitecore 6.5. Only difference that I can note is home item have different template and layout. Can you point me to any explanation of this for further investigation?
Hi John, I want to add my own timers inside the Sitecore profile and trace in debugmode. Do you have a c# example on how I could achieve that?