title: How DbContext and connections to DB should be implemented to handle load testing?
body: <p>I have recently start implementing some load testing.
  I am using .NetCore, EF Core 2.2 and Postgres.</p>
  
  <p>I am calling my test server (with<code>HttpClient</code> <code>client.PostAsync("/api/resource");</code>).</p>
  
  <p>I found that few of my requests fails because of too many connections (<code>The connection pool has been exhausted, either raise MaxPoolSize (currently 100) or Timeout (currently 15 seconds)</code>). So I implemented such approach:</p>
  
  <pre><code>services.AddDbContext&lt;MyDbContext&gt;(optionsAction: optionsBuilder =&gt;
      optionsBuilder.UseNpgsql(Config.ConnectionString,
      optionsAction =&gt;
      {
          optionsAction.EnableRetryOnFailure(5, TimeSpan.FromSeconds(10), null);
      }));
  </code></pre>
  
  <p>it helped a bit, but still, when calling with e.g. 500 requestes I got errors.</p>
  
  <p>I imagine, that it should work in a way, that e.g. if system is able to handle 100 requests at the same time (e.g. 100 connections to DB), the remaining requests (which uses <code>MyDbContext</code>) should wait (rather than fail).</p>
  
  <p>So my questions are:</p>
  
  <ol>
  <li>Is it normal that with high load, the requests will fail because of maximum of possible concurrent connections?</li>
  <li>If above is true - the normal approach is to use <code>EnableRetryOnFailure</code>?</li>
  <li>Is it possible to make other requests to wait in non blocking way (e.g. max 20 seconds) until there are some connections available?</li>
  <li>Or maybe there is other configuration option (in EF core, or in MVC) to make other requests to wait for available connection (from connection pool) instead of failing with exception?</li>
  </ol>