Using Log Analytics to efficiently monitor Azure virtual machine disk throttling.
Application Insights is an Azure-hosted service which provides for in-depth application monitoring, whether running in the cloud or on-premise. It provides powerful tools for monitoring, analysis, and diagnosis, with capabilities such as live metrics streaming, tracking response times and failure rates, and much more.
Performance (aka. Perfmon) Counters are critical to understanding the health of and diagnosing issues on Windows. In recent performance and scalability testing of a solution built on top of Azure Service Fabric, we collected Perfmon Counters across 15 VMs and sent them to Log Analytics. This was very helpful; however, there were times when we wanted them to be real time.
Do I need to add more servers if my user load grows by 10% each month for the next 12 months? That is a hard question to answer. Unless you have an Application Platform Management solution, it is hard to correlate function calls to CPU time and response times.
As you may know from my previous posts “The ‘in’-modifier and the readonly structs in C#” and “Performance traps of ref locals and ref returns in C#”, structs are trickier then you might think. Mutability aside, the behavior of readonly and non-readonly structs in “readonly”
The C# language from the very first version supported passing arguments by value or by reference. But before C# 7 the C# compiler supported only one way of returning a value from a method (or a property) – returning by value.
The async series
Dissecting the async methods in C#.
Extending the async methods in C#.
The performance characteristics of the async methods in C#.
One user scenario to rule them all.
In the last two blog posts we’ve covered the internals of async methods in C# and then we looked at the extensibility points the C# compiler provides to adjust the behavior of async methods.
Today I want to talk about one interesting optimization pattern that you may face in framework code or in high-performance libraries.
The idea is simple: suppose you have a commonly used method that has two execution paths – one is very common and simple,