The readme.md for Improper Instantiation (https://github.com/mspnp/performance-optimization/tree/master/ImproperInstantiation) contains a broken link to "Detailed Documentation," which points to https://github.com/mspnp/performance-optimization/blob/master/ImproperInstantiation/docs/ImproperInstantiation.md.

That file does not exist.

The ImproperInstantiation article makes a recommendation to reuse a single HttpClient instance for handling multiple requests.

The article even has this note:

Note: The key element of this anti-pattern is that an application repeatedly creates and destroys instances of a shareable object. If a class is not shareable (if it is not thread-safe), then this anti-pattern does not apply.

But the documentation of HttpClient says:

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Is this an error in the HttpClient docs, or is the ImproperInstantiation article wrong?

We should include a common ReSharper settings file

The new Azure portal makes it easy to provision an AdventureWorks db, however it uses a newer schema that differs from what we've been testing with.
We will continue to use the old schema (since it doesn't affect the perf tests), but we should be very clear about this in the README.

These single instances are very broadly useful objects that people will want to be able to use in very simple contexts. Azure function promotes and encourages smaller/simpler functions for simple use cases. In such contexts, the "try with resources + a lambda" style can give developers access to the instance and the freedom to use it however they want at the callsite, without having to wrap all their various HTTP requests in separate class methods, and go deep into abstractions with lots of boilerplate.

Again, it's an alternative style that makes it easier to use HttpClient in a healthy way for simple functions.

Here's an example for HttpClient

  public class SingleHttpClient
   {
       private static readonly HttpClient HttpClient;

       static SingleHttpClient()
       {
           HttpClient = new HttpClient();
       }

       public void DoWithClient<T>(Action<HttpClient> action)
       {
           action(HttpClient);
       }

       public async Task DoWithClient(Action<HttpClient> action)
       {
           await Task.Run(() => action(HttpClient));
       }

       public T DoWithClient<T>(Func<HttpClient, T> func)
       {
           return func(HttpClient);
       }

       public async Task<T> DoWithClient<T>(Func<HttpClient, Task<T>> func)
       {
           return await func(HttpClient);
       }
   }

And then to use., something like this...

        HttpResponseMessage response = await new SingleHttpClient()
                .DoWithClient(async (client) => await client.GetAsync("http://somehost:8080/api/"));

And, because this is a composeable style, you could write a DocumentClient using the same strategy, which calls upon this SingleHttpClient class just like the user would.

Just a thought, thanks for the great content here.

Some projects are named like this:

While some are named like this:

We should be consistent.

We should remove 'provisioning' folder and move script file to root if it's useful. Is it still valid?
We should also modify the anti-pattern template. It doesn't refrect the actual structure.

Our markdown should be readable when not rendered (as much as is reasonable).

• not long lines
• tool tips on imgs
• clean tables
• etc

When a pattern doesn't contain an AzureCloudService folder, it's a Web App (formerly Web site).
Let's point this out, just to eliminate possible confusion.

The Chatty IO sample needs to be completed with the following:

• Add and configure Azure cloud configuration project
• Connect to SQL Azure database instead of local database

All solutions should have a "Solution Items" folder containing the markdown documentation for the pattern and the LICENSE file.

We need to describe how we went about testing each antipattern.

• What did our deloyment look like?
• How were the load tests configured?
• What were our reasons for choosing these settings?

After mergingg #69, since it will significantly affect the results.
//cc @dragon119

In UnnecessaryRowsController,

                var salesPersons = await context.SalesPersons
                    .Include(sp => sp.SalesOrderHeaders) // This include forces eager loading.
                    .ToListAsync();

should match

                var query = from sp in context.SalesPersons
                            from soh in sp.SalesOrderHeaders
                            select soh.TotalDue;

Every C# file should have a copyright header as follows:

// Copyright (c) Microsoft. All rights reserved.
// Licensed under the MIT license. See LICENSE file in the project root for full license information.

We also then need a LICENCE file. :)

Really great stuff here but being able to determine when a class\methods is shareable seems to be 'conflicting'. Example of the HttpClient, talked about in the docs/ImproperInstantiation.md doc. If I go look at the docs for it states the following

'Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.'

The HttpClient.GetStringAsync is not marked as 'public static' so it appears to not be thread safe to me. Am I missing something here?

Let me just start by saying that i admire the work you guys put into these performance optimization documents and that the level of detail and attention is probably unprecedented.

If i may, i'd like to bring this to your attention:
In the Chatty IO document here https://github.com/mspnp/performance-optimization/blob/master/ChattyIO/docs/ChattyIO.md, after recommending buffering data into memory

You should consider the following points:

• [...]
• [...]
• Data buffered in memory to optimize write requests is vulnerable if the application crashes and may be lost.

the reader might feel that he or she just traded performance for risk and is probably a bit dissapointed. Which is a fair trade in most situations. But, am i completely wrong in saying this is one scenario in which a Queue would make sense, thus alleviating much of the risk of data loss given its durable nature?

In this document
https://github.com/mspnp/performance-optimization/blob/master/BusyFrontEnd/docs/BusyFrontEnd.md

Using a worker role is simply one solution. If you are using Azure Websites, you can use other options such as WebJobs.

Webjobs are running inside the same instance as the Azure Website, so it's not going to have a decoupling effect. That's what's i've seen in production. Sure you may scale out to let's say 10 instances (so, 10 x Webjobs) but i feel like this has the same effect as just doing 10 x WebRole.

(The Hanselman):
http://www.hanselman.com/blog/IntroducingWindowsAzureWebJobs.aspx

WebJobs aims to make developing, running, and scaling this easier. They are built into Azure Websites and run in the same VM as your Web Sites.