Skip to main content

Upcoming presentation on web application performance: why is this web app running slowly?

The venue is the next Seattle Code Camp meeting on September 13 at Seattle University. See https://seattle.codecamp.us/Schedule for details.

The presentation slides are available on SlideShare here.

I am also scheduled to give a similar presentation at the October meeting of the local .NET Developer's Association, to be held an the main Microsoft Redmond campus after hours on October 6. See http://www.meetup.com/NET-Developers-Association/ for details.

I have written a little something about this topic in the past, for example, here: http://performancebydesign.blogspot.com/2013/10/page-load-time-and-yslow-scalability.html. The latest presentation expands upon the ideas presented there, but also introduces a new ETW-based tool for monitoring web application response times for Windows apps, which I will be demo-ing.

Of course, I will have a lot more to say on this topic in future blog posts on the subject.

Comments

Post a Comment

Popular posts from this blog

High Resolution Clocks and Timers for Performance Measurement in Windows.

Within the discipline of software performance engineering (SPE), application response time monitoring refers to the capability of instrumenting application requests, transactions and other vital interaction scenarios in order to measure their response times. There is no single, more important performance measurement than application response time, especially in the degree which the consistency and length of application response time events reflect the user experience and relate to customer satisfaction. All the esoteric measurements of hardware utilization that Perfmon revels in pale by comparison. Of course, performance engineers usually still want to be able to break down application response time into its component parts, one of which is CPU usage. Other than the Concurrency Visualizer that is packaged with the Visual Studio Profiler that was discussed  in the previous post , there are few professional-grade, application response time monitoring and profi...
3 comments
Read more

Using xperf to analyze CSwitch events

Continuing the discussion from the previous blog entry on event-driven approaches to measuring CPU utilization in Windows ... Last time around I discussed the same CPU busy calculations that the Resource Manager in Windows 6 & 7 makes. This same calculation can also be performed after the fact using the event data from ETW. This is the technique used in the Windows Performance Toolkit (WPT, but which is better known around Microsoft as xperf), for example, to calculate CPU usage metrics. Once you have downloaded and installed the Windows Performance Toolkit, you can launch a basic ETW collection session using the following xperf command: xperf -on DiagEasy Then, after you have accumulated enough data, issue another command to stop tracing and capture the event stream to a file: xperf -d cputrace.etl Next, process the cputrace.etl file using the xperfview app. After the trace file is loaded, xperfview provides visualizations that are very similar to ResMon. ...
Post a Comment
Read more

Monitoring SQL Server: the OS Wait stats DMV

This is the 2nd post in a series on SQL Server performance monitoring, emphasizing the use of key Dynamic Management View. The series starts here : OS Waits  The consensus among SQL Server performance experts is that the best place to start looking for performance problems is the OS Wait stats from the sys.dm_os_wait_stats DMV. Whenever it is running, the SQL Server database Engine dispatches worker threads from a queue of ready tasks that it services in a round-robin fashion. (There is evidently some ordering of the queue based on priority –background tasks with lower priority that defer to foreground tasks with higher priority.) The engine records the specific wait reason for each task waiting for service in the queue and also accumulates the Wait Time (in milliseconds) for each Wait reason. These Waits and Wait Time statistics accumulate at the database level and reported via the sys.dm_os_wait_stats DMV. Issuing a Query like the following on one of my SQL Server test...
Post a Comment
Read more