LDNUG - Progressive .NET: Profiling .NET apps with ANTS Profiler
•Download as PPTX, PDF•
1 like•296 views
These are the slides from my recent LDNUG talk on profiling .NET applications: http://www.meetup.com/London-NET-User-Group/events/228252666/. Most of the talk was taken up by giving a demo of two handy tools that will help you find and fix problems quickly: ANTS Performance Profiler and ANTS Memory Profiler. The main benefit of the slides is that they have my contact details on them. If you have any questions about the talk, or any performance problems you'd like to talk over, please do get in touch. I'm always happy to help.
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
LDNUG - Progressive .NET: Profiling .NET apps with ANTS Profiler
- 1. Profiling .NET apps with ANTS Profiler Bart Read Web and database performance consultant Previously: Red Gate Software Email: bart@bartread.com Twitter: @bart_read Github: https://github.com/bartread www.bartread.com https://arcade.ly/
- 2. Demo: ANTS Performance Profiler • Download and try: http://www.red- gate.com/products/dotnet-development/ants- performance-profiler/ • Configuration • Collecting data • Analysing data • .NET code • HTTP requests • SQL • Memory usage
- 5. Grant Fritchey’s FREE eBook on execution plans: http://www.red- gate.com/community/books/s ql-server-execution-plans-ed-2
- 6. ANTS Performance Profiler: Execution Plan View • Shows execution plan for a given set of query parameters • Based on http://www.supratimas.com/
- 9. Common SQL Performance Problems • Missing indexes • Queries with poor selectivity • WHERE columnName <> someValue • WHERE IN, WHERE NOT IN • CROSS JOIN, CROSS APPLY • Columns with poor selectivity, such as BIT • Complex queries (e.g., nested views) • Blocking and deadlocking • Distributed queries
- 10. Demo: ANTS Memory Profiler • Download and try: http://www.red- gate.com/products/dotnet-development/ants- memory-profiler/ • Configuration (basically same as APP • Collecting data – snapshots • Analysing data • Comparing snapshots • Filtering • Identifying leaked types • Relating back to code - harder
- 15. Useful Ancillary Tools from Red Gate
- 16. Questions? Bart Read www.bartread.com https://arcade.ly/ Email: bart@bartread.com Twitter: @bart_read Github: https://github.com/bartread
Editor's Notes
- There are other chunks of data we can look at, for example, file I/O, but the above are generally the most interesting.
- SQL Server Management Studio’s execution plan view. Better than nothing, but it’s not always easy to see where the most expensive operations are happening, especially not for complex queries with large execution plans. Grant’s book provides an invaluable resource for understanding execution plans and should be your companion when you’re investigating them.
- ANTS Performance Profiler now includes its own execution plan visualiser, based on the one you can find at http://www.supratimes.com/. Only caveat with this is that to view execution plans you need to be able to connect to the database, or at least a copy of it, because ANTS Performance Profiler needs to rerun the query in order to get the execution plan from SQL Server.
- Keep an eye out for high CPU, high I/O, large numbers of records in intermediate result sets (your query isn’t selective enough, soon enough), and large amounts of data (size).
- Quite handy because if you click on any of the operations it’ll take you directly to the corresponding node in the execution plan diagram.
- The most common problems I encounter, in no particular order, are in red. When a performance problem is isolated in SQL Server, it’s generally NOT SQL Server’s fault, but a problem with the schema design (often indexes), or a poorly written (or generated) query. Be aware that CROSS JOIN and CROSS APPLY can lead to an explosion in the number of rows in a result set. That being said, so can overzealous use of LEFT JOIN, or RIGHT JOIN, across too many tables. Nested views are an issue because they mask complexity that can easily trip up unway developers who build queries using them.
- This shows some (redacted) real data from a production profiling session. Not that we appear to be leaking ItemControllers. (I’m comparing first and last snapshots, and looking only at objects for which I have code, and which are “new” in the second snapshot.) In this case the ItemController should have been cleaned up after the view had been served up.
- Here are the individual item controllers. What I need to do is have a look at the instance retention graph for one or more of them and find out what’s holding on to them.
- The instance retention graphs for all these ItemControllers look like this. You can see that Castle Windsor – the DI container used in this site – is implicated.
- Here’s a zoomed in view of part of the graph. Note the presence of Windsor types. The issue turned out to be the way the lifestyle of these objects was configured such that Windsor continued to track them even after the application had finished with them. Hence the leak, and ever growing memory usage, as the site was used.
- You’ll probably find yourself having to write some SQL in SQL Server Management Studio to fix any SQL related performance problems. I’d recommend a few tools to help here: SQL Prompt – a SQL autocomplete/intellisense tool from Red Gate, which is much better than SSMS’s (or Visual Studio’s) built-in SQL intellisense, and will enable you to bash out SQL much more quickly. Think of it a bit like ReSharper for SQL. SQL Dependency Tracker – still, in my opinion, the best tool for quickly visualising a SQL Server database. Generally I just add all the objects in the database (it’ll handle up to 5000-6000 objects gracefully), then filter out everything except tables and views. I can then add other objects back in if necessary. You can use the tool windows on the right of the screen for filtering and grouping. Other handy tools: Performance Monitor – gives you access to Windows performance counters. As much as these counters aren’t perfect they can be quite helpful. There are a load of SQL Server counters that can be useful. ANTS Profiler will allow you to graph certain counters whilst you profile your app, but it doesn’t offer anything like the full set. Fiddler – can be helpful to sniff HTTP traffic. Whilst Chrome Dev Tools is fine for traffic to/from the browser, it doesn’t help so much with anything else. Fiddler, despite being a bit of a horror show to use, is hugely powerful. I highly recommend “Debugging with Fiddler: the complete reference…” by its creator, Eric Lawrence: https://www.amazon.co.uk/Debugging-Fiddler-complete-reference-Debugger/dp/1511572906/ref=sr_1_1?ie=UTF8&qid=1466696936&sr=8-1&keywords=fiddler Chrome Dev Tools, for obvious reasons – includes some decent client-side profiling tools, which can come in particularly handy when you’re working with a (bloated?) framework like Angular SQL Server Profiler – not on the slide, and now deprecated by Microsoft (although with no good replacement yet available), SQL Profiler is still one of the best ways to identify slow queries on a running SQL Server instance. Like Fiddler, it’s nasty to use, but you can quickly harvest a lot of useful data if you invest an hour or two learning how.