MSDN Magazine - March 2008 - (Page 16)

Figure 3 VADump Output Category Page Table Pages Other System Code/StaticData Heap Stack Teb Mapped Data Other Data Total Total Total Grand Total Modules Dynamic Data System Working Set Pages 177 39 8169 14042 0 0 8 1 8169 14051 216 22436 Total KBytes 708 156 32676 56168 0 0 32 4 32676 56204 864 89744 Private Shareable KBytes KBytes 708 0 156 0 2160 8336 56168 0 0 0 0 0 0 4 4 0 2160 56172 864 59196 8336 4 0 8340 Shared KBytes 0 0 22180 0 0 0 28 0 22180 28 0 22208 Module Working Set Contributions in pages Total Private Shareable Shared Module 72 2 70 0 HeadTrax - HeadTrax.exe 107 7 0 100 ntdll.dll 37 4 6 27 mscoree.dll 77 3 0 74 KERNEL32.dll 6 2 0 4 LPK.DLL 27 4 0 23 USP10.dll 116 4 0 112 comctl32.dll 878 23 79 776 mscorwks.dll Heap Working Set Contributions 0 pages from Process Heap (class 0x00000000) 0 pages from Process Heap (class 0x00000000) 9332 pages from Process Heap (class 0x00000000) 0x0255850F - 0xC255350F 9332 pages 0 pages from Process Heap (class 0x00000000) 0 pages from Process Heap (class 0x00000000) 4710 pages from Process Heap (class 0x00000000) 0x00040000 - 0x10040000 4710 pages 0 pages from Process Heap (class 0x00000000) Stack Working Set Contributions 0 pages from stack for thread 00001018 0 pages from stack for thread 000017EC 0 pages from stack for thread 0000187C Warm startup is CPU-bound because the code is already in memory (so there is no need for additional I/O) but code needs to be JITed before the application can run. With the .NET Framework today, the native code generated by the JIT is not saved from one execution of an application to the next. If you see that warm startup is not significantly smaller than cold startup, you need to discover what is consuming CPU cycles (because most of the code is preloaded in a warm startup and is unlikely to be I/O bound). The likely culprits, then, include large volumes of code that must be JITed or complex computations that the application must perform. To determine if JITing is the issue, you can check the performance counter .NET CLR JIT\% time in JIT. If the value is not high (for instance more than 30%-40% for most of the startup time), it means that JIT is not likely to be a major contributor and you should use a profiler to determine which functions in your app consume the most CPU time. Keep in mind that the counter is updated only if methods are actually JITed. This means that after the last method has been JITed the counter will still report the last value; it will not drop to zero. Therefore, make sure you look at the counter only for the first few seconds of the app’s startup; at that time you are likely to see the counter increase very fast, indicating that the spike in CPU utilization is caused by the JIT compiler. You should also be aware that any application that’s loaded when the user logs on will have to compete for I/O with other services and applications, making startup time even worse. Therefore, avoid adding applications to the startup group whenever possible (a good tool for determining what applications are set to run at machine setup is AutoRuns, available at microsoft.com/technet/sysinternals/Security/Autoruns.mspx). user experience, so don’t draw any concrete conclusions about the actual performance of your application with the data you collect with SuperFetch turned off. Two performance counters that you can use to see the impact of cold startup on I/O are % processor time and % disk read time. If I/O dominates cold startup, which it should, you should see a big difference between % processor time and disk Since processing is usually read time. Performance not the bottleneck in a cold counters can be collected startup, the initial goal of using PerfMon (see the “Startup Performance Reany application startup sources” sidebar for more performance investigation is information). to reduce disk access. In Figure 1, the red line represents % disk read time and the green line represents % processor time. In the case of cold startup, you can see that CPU usage is relatively low compared with the time spent reading from disk. The second time the application is launched, you are in the warm startup scenario so the performance counter should show a different picture. In Figure 2, the scenario is CPU bound, and as you can see, % disk read is very low compared with % processor time. 16 msdnmagazine CLR Inside Out The next step is to determine what is loaded from disk and find out if there is code that is being loaded unintentionally. The quickest way to determine what is loaded into memory is to use the VADump tool (you can find it in the Windows Platform SDK). Figure 3 shows an excerpt of the report that’s generated by running the following command: VADump –sop Identify Code Loaded from Disk One important thing to keep in mind is that VADump shows only what is loaded in memory at the time the tool is run, so it might miss modules that are loaded in memory for only a short period of time. It also doesn’t show the part of the app (either code or data) that has been paged out to disk. The goal is to review the VADump report to determine if it makes sense to load all the modules in the list. For instance, if your application does not use XML and you see that System.Xml was loaded, you need to investigate. You can find out what loaded an assembly by using the sxe command in the Windows debugger (windbg). The “sxe ld: ” command causes the debugger to break when the specified DLL is loaded. You can then check the call stack to find out which function caused the DLL to be loaded in memory. This aspect of the investigation should not be underestimated. It is very easy to lose sight of what the application actually loads in memory. http://microsoft.com/technet/sysinternals/Security/Autoruns.mspx http://microsoft.com/technet/sysinternals/Security/Autoruns.mspx

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.