When addressing website performance issues, developers typically jump to conclusions, focusing on the perceived causes rather than uncovering the real causes through research.

Mitchel Sellers will show you how to approach website performance issues with a level of consistency that ensures they're properly identified and resolved so you'll avoid jumping to conclusions in the future.

Watch the webinar to learn:

  • What aspects of website performance are commonly overlooked

  • What metrics & standards are needed to validate performance

  • What tools & tips are helpful in assisting with diagnostics

  • Where you can find additional resources and learning

Applying a methodical approach to website performance on Vimeo.

You can find the slide deck here:


Q: Are there any specific tools that we can use to load test APIs?

A: Google PageSpeed Insights works only for public facing stuff. YSlow as a browser plugin will work on any page including authenticated, unauthenticated, or public facing so that might be a good choice.

Q: What is a normal/acceptable request per second (RPS) for a CMS site?

A: The acceptable number really depends on the hardware. From my experience with working with DotNetNuke content management system on an Azure A1 server, we start to see failures at about 102 - 105 requests per second. However, it really varies and will depend on what your application is doing (number of requests, number of static files it has, etc.). While there's not necessarily a gold standard, if you see anything under 100, it's typically a sign of an application configuration or other issue rather than the fact that you do not have a large enough hardware.



About the speaker, Mitchel Sellers

Mitchel Sellers

Mitchel Sellers is a Microsoft C# MVP, ASPInsider and CEO of IowaComputerGurus Inc, focused on custom app solutions built upon the Microsoft .NET Technology stack with an emphasis on web technologies. Mitchel is a prolific public speaker, presenting topics at user groups and conferences globally, and the author of "Professional DotNetNuke Module Programming" and co-author of "Visual Studio 2010 & .NET 4.0 Six-in-One".
Mitchel's blog.



We’re excited to announce the first public preview of PostSharp 5.0, available for download from our website and from NuGet Gallery (make sure to enable pre-releases). Starting from today, we’re going to update the preview every third week.

In this blog post, I would like to focus on the most demanded feature that is already present in the current preview: Support for .NET Core 1.0 (CLI).

After so many unsuccessful platforms pushed by Microsoft during the last years (I’m thinking of you, Windows Phone), it’s good to see real customer demand for .NET Core. Some corporate customers already see .NET Core as a successor to Java, captured in the hands of the evil Oracle. We’re excited to see some real enthusiasm (not just marketing-driven hype) for the initiative.


PostSharp 5.0 has partial and unfinished support for .NET Core 1.0.

To add PostSharp to your .NET Core projects, follow the procedure described in this KB article.


However it’s a real challenge for us to support this platform, so we have split the effort into several phases. Our objective with PostSharp 5.0 is to build on Windows, run everywhere. Today, we’re releasing the first bits. However, the work is still in progress, and you will see more features appear in the next previews.

The following NuGet packages have already been ported to .NET Core 1.0:

  • PostSharp
  • PostSharp.Patterns.Common
  • PostSharp.Patterns.Diagnostics
  • PostSharp.Patterns.Diagnostics.Console
  • PostSharp.Patterns.Diagnostics.AspNetCoreLogging

A few notes and disclaimers: it is not clear yet whether PostSharp 5.0 RTM will support .NET Core 1.0 or .NET Core 1.1 with its new build system based on MSBuild and CSProj. We will take the decision once the roadmap of .NET Core 1.1 will be clearer. Keep in mind that we may drop support for .NET Core 1.0 before PostSharp 5.0 reaches RTM.

Note that we’re prioritizing our work according to the needs of our commercial customers. If you’re a commercial customer and interested in .NET Core, please reach out to our technical support and express your priorities.

Splitting of Tools and Redistributable Packages

More and more customers are using NuGet as an internal vehicle to distribute binaries across different development teams. They use an internal repository, to which the continuous integration system automatically uploads successful builds. Many of these customers have requested a way to express a run-time dependency on PostSharp without necessarily including PostSharp in the build process. You may have of course the same requirements if you want to upload to the public NuGet Gallery a package built with PostSharp, but which can be referenced without requiring the referencing project to be enhanced by PostSharp.

For this scenarios, it became necessary to split all packages into a run-time part and a build-time part. Furthermore, .NET Core requires build-time tools and run-time dependencies to be packaged separately.

Therefore, we decided to split all packages into two parts: one package with the run-time assets, and another package with the build-time assets.

Although the most popular convention seems to be for the build-time package to have the BuildTools suffix, we decided otherwise in order to maintain backward compatibility. We will be following another popular convention, where the build-time package will be unsuffixed, and the run-time package will have the Redist suffix. (Note that the current preview has the Redistributable suffix. This will be changed in the next preview.)

We’ve already split the PostSharp package in two parts. In the next previews, we will continue and split all relevant packages.


We’ve done good progress in supporting .NET Core 1.0 and will do more during the next weeks. Feedback? Questions? Don’t hesitate to share them as comments to this blog post.

Happy PostSharping!


Today we’re excited to announce the release of PostSharp 4.3 RTM, available for download on Visual Studio Gallery and NuGet.  PostSharp 4.3 addresses the most important concerns of current customers.  It focuses on improving the current experience without adding brand new features.

In a nutshell, PostSharp 4.3 brings you:

  • Improved build-time performance: up to 3x faster
  • Improved debugging experience
  • Alternative to NuGet-based deployment
  • Command-line tool
  • Improvements in the NotifyPropertyChanged aspect
  • Some licensing goodness for everybody.

You can watch the recording of the webinar What's New in PostSharp 4.3 that shows the updates of the new version.

Let’s look at these improvements one by one:

Improved build-time performance

PostSharp 4.3 is up to 3 times faster than PostSharp 4.2. The real figures will depend on the number and size of your projects, how many aspects are being used, and whether you enabled the solution-wide build optimizations. This option can be found under the PostSharp tab of the Solution properties in Visual Studio.

What is does is to try to build the whole solution in a single AppDomain (or as few as possible) so the overhead per project is much smaller.

Improved debugging experience

Debugging an application enhanced with aspects is now even easier thanks to the following improvements:

  • Full support for Just My Code.

  • During Step Into, aspect code is now stepped over by default.

  • The call stack no longer contains PostSharp implementation details by default.

To learn more about these features, see the blog post New in PostSharp 4.3 Preview: Improved Debugging Experience.

Alternative to NuGet-based deployment

Between versions 3.0 and 4.2, the PostSharp compiler and libraries were only distributed as NuGet packages. Let’s face it: some companies did not like this at all that we forced them to use NuGet. Starting from version 4.3, we are re-introducing the old good zip file, and integrate it better with PostSharp Tools for Visual Studio.

For more information, see the blog post New in PostSharp 4.3 Preview – An alternative to NuGet.

Command-line tool

Using PostSharp as a command-line tool is now a supported and documented scenario. It means you can now even instrument assemblies that you are not building yourself – whether or not you have its source code.

You can see how it works in the blog post New in PostSharp 4.3 Preview: Command-Line Interface.

Some licensing goodness for everybody

We hate licensing just as you do but we’ve working on it in PostSharp 4.3 and we’re glad to come with two major improvements:

  • You no longer need a license to build source code that you just checked out from Git or TFS but did not create/edit yourself.
  • The limitations of PostSharp Express for new users are now much simpler: you get everything of PostSharp Ultimate, but only if you add aspects to 10 classes per project.

Improvements in the NotifyPropertyChanged aspect

Due to popular demand, we’ve added support for Caliburn.Micro and MVVM Light.

We’ve also added an option to suppress false positives. To enable the option (which has some runtime overhead and is disabled by default), set the PreventFalsePositives option when constructing the NotifyPropertyChanged aspect:

[NotifyPropertyChanged(PreventFalsePositives = true)]


With PostSharp 4.3, we’ve been addressing the top concerns of existing customers. PostSharp users will spend less time waiting for the build and will be much more productive while debugging. Plus, there’s a ton of improvements to make the deployment and the licensing of PostSharp easier.

PostSharp 4.3 is fully backward compatible with PostSharp 4.2, so it’s safe to update today.

Happy PostSharping!