Updates to ASP.NET Core Perf Recommendations (dotnet#19605)

* added IAsyncEnumerable to performance doc

* added in-process hosting to perf doc

* Added hosting link to perf doc

* Update aspnetcore/performance/performance-best-practices.md

Co-authored-by: Rick Anderson <3605364+Rick-Anderson@users.noreply.github.com>

* Update aspnetcore/performance/performance-best-practices.md

Co-authored-by: Rick Anderson <3605364+Rick-Anderson@users.noreply.github.com>

* Added IAsyncEnumerable feedback to perf doc

* Update performance-best-practices.md

* Update performance-best-practices.md

* Update performance-best-practices.md

* Update performance-best-practices.md

* Update performance-best-practices.md

Co-authored-by: Rick Anderson <3605364+Rick-Anderson@users.noreply.github.com>

aspnetcore/performance/performance-best-practices.md

@@ -42,6 +42,12 @@ A common performance problem in ASP.NET Core apps is blocking calls that could b
 
 A profiler, such as [PerfView](https://github.com/Microsoft/perfview), can be used to find threads frequently added to the [Thread Pool](/windows/desktop/procthread/thread-pools). The `Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start` event indicates a thread added to the thread pool. <!--  For more information, see [async guidance docs](TBD-Link_To_Davifowl_Doc)  -->
 
+## Return IEnumerable\<T> or IAsyncEnumerable\<T>
+
+Returning `IEnumerable<T>` from an action results in synchronous collection iteration by the serializer. The result is the blocking of calls and a potential for thread pool starvation. To avoid synchronous enumeration, use `ToListAsync` before returning the enumerable.
+
+Beginning with ASP.NET Core 3.0, `IAsyncEnumerable<T>` can be used as an alternative to `IEnumerable<T>` that enumerates asynchronously. For more information, see [Controller action return types](xref:web-api/action-return-types#return-ienumerablet-or-iasyncenumerablet).
+
 ## Minimize large object allocations
 
 The [.NET Core garbage collector](/dotnet/standard/garbage-collection/) manages allocation and release of memory automatically in ASP.NET Core apps. Automatic garbage collection generally means that developers don't need to worry about how or when memory is freed. However, cleaning up unreferenced objects takes CPU time, so developers should minimize allocating objects in [hot code paths](#understand-hot-code-paths). Garbage collection is especially expensive on large objects (> 85 K bytes). Large objects are stored on the [large object heap](/dotnet/standard/garbage-collection/large-object-heap) and require a full (generation 2) garbage collection to clean up. Unlike generation 0 and generation 1 collections, a generation 2 collection requires a temporary suspension of app execution. Frequent allocation and de-allocation of large objects can cause inconsistent performance.
@@ -341,3 +347,11 @@ Checking if the response has not started allows registering a callback that will
 ## Do not call next() if you have already started writing to the response body
 
 Components only expect to be called if it's possible for them to handle and manipulate the response.
+
+## Use In-process hosting with IIS
+
+Using in-process hosting, an ASP.NET Core app runs in the same process as its IIS worker process. In-process hosting provides improved performance over out-of-process hosting because requests aren't proxied over the loopback adapter. The loopback adapter is a network interface that returns outgoing network traffic back to the same machine. IIS handles process management with the [Windows Process Activation Service (WAS)](/iis/manage/provisioning-and-managing-iis/features-of-the-windows-process-activation-service-was).
+
+Projects default to the in-process hosting model in ASP.NET Core 3.0 and later.
+
+For more information, see [Host ASP.NET Core on Windows with IIS](xref:host-and-deploy/iis/index)