.NET Framework Connection Pool Limits and the new Azure SDK for .NET

To build scalable applications it’s important to understand how your downstream dependencies scale and what limitations you can hit.

The majority of Azure services expose functionality over HTTP REST APIs. The Azure SDKs, in turn, wrap the HTTP communication into an easy-to-use set of client and model types.

Every time you call a method on a Client class, an HTTP request is sent to the service. Sending an HTTP request requires a socket connection to be established between client and the server. Establishing a connection is an expensive operation that could take longer than the processing of the request itself. To combat this, .NET maintains a pool of HTTP connections that can be reused instead of opening a new one for each request.

The post details the specifics of HTTP connection pooling based on the .NET runtime you are using and ways to tune it to make sure connection limits don’t negatively affect your application performance.

NOTE: most of this is not applicable for applications using .NET Core. See .NET Core section for details.

.NET Framework

Connection pooling in the .NET framework is controlled by the ServicePointManager class and the most important fact to remember is that the pool, [by default](https://docs.microsoft.com/dotnet/api/system.net.servicepointmanager.defaultconnectionlimit), is limited to **2** connections to a particular endpoint (host+port pair) in non-web applications, and to **unlimited** connection per endpoint in ASP.NET applications that have autoConfig enabled (without autoConfig the limit is set to 10). After the maximum number of connections is reached, HTTP requests will be queued until one of the existing connections becomes available again.

Imagine writing a console application that uploads files to Azure Blob Storage. To speed up the process you decided to upload using using 20 parallel threads. The default connection pool limit means that even though you have 20 BlockBlobClient.UploadAsync calls running in parallel only 2 of them would be actually uploading data and the rest would be stuck in the queue.

NOTE: The connection pool is centrally managed on .NET Framework. Every ServiceEndpoint has one or more connection groups and the limit is applied to connections in a connection group. HttpClientcreates a connection group per-client so every HttpClient instance gets it’s own limit while instances of HttpWebRequest reuse the default connection group and all share the same limit (unless ConnectionGroupName is set). All Azure SDK client by default use a shared instance of HttpClientand as such share the same pool of connections across all of them.

#azure sdk #.net #azuresdk #clientlibraries #connectionpool #httpclient #sdk #servicepointmanager

What is GEEK

Buddha Community

.NET Framework Connection Pool Limits and the new Azure SDK for .NET

To build scalable applications it’s important to understand how your downstream dependencies scale and what limitations you can hit.

The majority of Azure services expose functionality over HTTP REST APIs. The Azure SDKs, in turn, wrap the HTTP communication into an easy-to-use set of client and model types.

Every time you call a method on a Client class, an HTTP request is sent to the service. Sending an HTTP request requires a socket connection to be established between client and the server. Establishing a connection is an expensive operation that could take longer than the processing of the request itself. To combat this, .NET maintains a pool of HTTP connections that can be reused instead of opening a new one for each request.

The post details the specifics of HTTP connection pooling based on the .NET runtime you are using and ways to tune it to make sure connection limits don’t negatively affect your application performance.

NOTE: most of this is not applicable for applications using .NET Core. See .NET Core section for details.

.NET Framework

Connection pooling in the .NET framework is controlled by the ServicePointManager class and the most important fact to remember is that the pool, [by default](https://docs.microsoft.com/dotnet/api/system.net.servicepointmanager.defaultconnectionlimit), is limited to **2** connections to a particular endpoint (host+port pair) in non-web applications, and to **unlimited** connection per endpoint in ASP.NET applications that have autoConfig enabled (without autoConfig the limit is set to 10). After the maximum number of connections is reached, HTTP requests will be queued until one of the existing connections becomes available again.

Imagine writing a console application that uploads files to Azure Blob Storage. To speed up the process you decided to upload using using 20 parallel threads. The default connection pool limit means that even though you have 20 BlockBlobClient.UploadAsync calls running in parallel only 2 of them would be actually uploading data and the rest would be stuck in the queue.

NOTE: The connection pool is centrally managed on .NET Framework. Every ServiceEndpoint has one or more connection groups and the limit is applied to connections in a connection group. HttpClientcreates a connection group per-client so every HttpClient instance gets it’s own limit while instances of HttpWebRequest reuse the default connection group and all share the same limit (unless ConnectionGroupName is set). All Azure SDK client by default use a shared instance of HttpClientand as such share the same pool of connections across all of them.

#azure sdk #.net #azuresdk #clientlibraries #connectionpool #httpclient #sdk #servicepointmanager

PostgreSQL Connection Pooling: Part 4 – PgBouncer vs. Pgpool-II

In our previous posts in this series, we spoke at length about using PgBouncer  and Pgpool-II , the connection pool architecture and pros and cons of leveraging one for your PostgreSQL deployment. In our final post, we will put them head-to-head in a detailed feature comparison and compare the results of PgBouncer vs. Pgpool-II performance for your PostgreSQL hosting !

The bottom line – Pgpool-II is a great tool if you need load-balancing and high availability. Connection pooling is almost a bonus you get alongside. PgBouncer does only one thing, but does it really well. If the objective is to limit the number of connections and reduce resource consumption, PgBouncer wins hands down.

It is also perfectly fine to use both PgBouncer and Pgpool-II in a chain – you can have a PgBouncer to provide connection pooling, which talks to a Pgpool-II instance that provides high availability and load balancing. This gives you the best of both worlds!

PostgreSQL Connection Pooling: Part 4 – PgBouncer vs. Pgpool-II

CLICK TO TWEET

Performance Testing

While PgBouncer may seem to be the better option in theory, theory can often be misleading. So, we pitted the two connection poolers head-to-head, using the standard pgbench tool, to see which one provides better transactions per second throughput through a benchmark test. For good measure, we ran the same tests without a connection pooler too.

Testing Conditions

All of the PostgreSQL benchmark tests were run under the following conditions:

1. Initialized pgbench using a scale factor of 100.
2. Disabled auto-vacuuming on the PostgreSQL instance to prevent interference.
3. No other workload was working at the time.
4. Used the default pgbench script to run the tests.
5. Used default settings for both PgBouncer and Pgpool-II, except max_children*. All PostgreSQL limits were also set to their defaults.
6. All tests ran as a single thread, on a single-CPU, 2-core machine, for a duration of 5 minutes.
7. Forced pgbench to create a new connection for each transaction using the -C option. This emulates modern web application workloads and is the whole reason to use a pooler!

We ran each iteration for 5 minutes to ensure any noise averaged out. Here is how the middleware was installed:

• For PgBouncer, we installed it on the same box as the PostgreSQL server(s). This is the configuration we use in our managed PostgreSQL clusters. Since PgBouncer is a very light-weight process, installing it on the box has no impact on overall performance.
• For Pgpool-II, we tested both when the Pgpool-II instance was installed on the same machine as PostgreSQL (on box column), and when it was installed on a different machine (off box column). As expected, the performance is much better when Pgpool-II is off the box as it doesn’t have to compete with the PostgreSQL server for resources.

Throughput Benchmark

Here are the transactions per second (TPS) results for each scenario across a range of number of clients:

#database #developer #performance #postgresql #connection control #connection pooler #connection pooler performance #connection queue #high availability #load balancing #number of connections #performance testing #pgbench #pgbouncer #pgbouncer and pgpool-ii #pgbouncer vs pgpool #pgpool-ii #pooling modes #postgresql connection pooling #postgresql limits #resource consumption #throughput benchmark #transactions per second #without pooling

jQuery Ajax CRUD in ASP.NET Core MVC with Modal Popup

In this article, we’ll discuss how to use jQuery Ajax for ASP.NET Core MVC CRUD Operations using Bootstrap Modal. With jQuery Ajax, we can make HTTP request to controller action methods without reloading the entire page, like a single page application.

To demonstrate CRUD operations – insert, update, delete and retrieve, the project will be dealing with details of a normal bank transaction. GitHub repository for this demo project : https://bit.ly/33KTJAu.

Sub-topics discussed :

• Form design for insert and update operation.
• Display forms in modal popup dialog.
• Form post using jQuery Ajax.
• Implement MVC CRUD operations with jQuery Ajax.
• Loading spinner in .NET Core MVC.
• Prevent direct access to MVC action method.

Create ASP.NET Core MVC Project

In Visual Studio 2019, Go to File > New > Project (Ctrl + Shift + N).

From new project window, Select Asp.Net Core Web Application_._

Once you provide the project name and location. Select Web Application(Model-View-Controller) and uncheck HTTPS Configuration. Above steps will create a brand new ASP.NET Core MVC project.

Setup a Database

Let’s create a database for this application using Entity Framework Core. For that we’ve to install corresponding NuGet Packages. Right click on project from solution explorer, select Manage NuGet Packages_,_ From browse tab, install following 3 packages.

Now let’s define DB model class file – /Models/TransactionModel.cs.

public class TransactionModel
{
    [Key]
    public int TransactionId { get; set; }

    [Column(TypeName ="nvarchar(12)")]
    [DisplayName("Account Number")]
    [Required(ErrorMessage ="This Field is required.")]
    [MaxLength(12,ErrorMessage ="Maximum 12 characters only")]
    public string AccountNumber { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Beneficiary Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BeneficiaryName { get; set; }

    [Column(TypeName ="nvarchar(100)")]
    [DisplayName("Bank Name")]
    [Required(ErrorMessage = "This Field is required.")]
    public string BankName { get; set; }

    [Column(TypeName ="nvarchar(11)")]
    [DisplayName("SWIFT Code")]
    [Required(ErrorMessage = "This Field is required.")]
    [MaxLength(11)]
    public string SWIFTCode { get; set; }

    [DisplayName("Amount")]
    [Required(ErrorMessage = "This Field is required.")]
    public int Amount { get; set; }

    [DisplayFormat(DataFormatString = "{0:MM/dd/yyyy}")]
    public DateTime Date { get; set; }
}

C#Copy

Here we’ve defined model properties for the transaction with proper validation. Now let’s define  DbContextclass for EF Core.

#asp.net core article #asp.net core #add loading spinner in asp.net core #asp.net core crud without reloading #asp.net core jquery ajax form #asp.net core modal dialog #asp.net core mvc crud using jquery ajax #asp.net core mvc with jquery and ajax #asp.net core popup window #bootstrap modal popup in asp.net core mvc. bootstrap modal popup in asp.net core #delete and viewall in asp.net core #jquery ajax - insert #jquery ajax form post #modal popup dialog in asp.net core #no direct access action method #update #validation in modal popup

Announcing Entity Framework Core (EF Core) 5 RC2

Today, the Entity Framework Core team announces the second release candidate (RC2) of EF Core 5.0. This is a feature complete release candidate of EF Core 5.0 and ships with a “go live” license. You are supported using it in production. This is a great opportunity to start using EF Core 5.0 early while there is still time to fix remaining issues. We’re looking for reports of any remaining critical bugs that should be fixed before the final release.

Prerequisites

EF Core 5.0 will not run on .NET Standard 2.0 platforms, including .NET Framework.

• The release candidates of EF Core 5.0 require .NET Standard 2.1.
• This means that EF Core 5.0 will run on .NET Core 3.1 and does not require .NET 5.
• To summarize: EF Core 5.0 runs on platforms that support .NET Standard 2.1.

How to get EF Core 5.0 Release Candidate 2

EF Core is distributed exclusively as a set of NuGet packages. For example, to add the SQL Server provider to your project, you can use the following command using the dotnet tool:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0-rc.2.20475.6

#.net #.net core #.net framework #asp.net #c# #entity framework #announcement #asp.net core #entity framework core

Azure SDK Release (June 2021)

Release Highlights

Welcome to the June release of the Azure SDK. We have updated the following libraries:

Stable Releases

• Azure Cognitive Search for .NET, Java (version 11.4), and JavaScript and Python (version 11.2)
• Adds stable features and bug fixes from the beta releases. See the Cognitive Search changelog for more details.
• Preview service features not generally available yet, like Semantic Search and Normalizers, are not included in this release.
• Support for geospatial types in core for .NET and Java.
• Support for knowledge store.
• Azure Data Tables version 12.0
• Read more here: Announcing the new Azure Data Table Libraries.
• Azure SDK for Python (Conda) packages are now generally available in the Microsoft channel.
• Read more here: Introducing the Azure SDK for Python (Conda).
• See also: https://anaconda.org/microsoft.
• Event Grid for Java (version 4.4), JavaScript and Python (version 4.3)
• Adds new system events definition for Storage Blob and Azure Communication Service.
• Form Recognizer version 3.1
• This release marks the stability of the changes introduced in package versions 3.1.0-beta.1 through 3.1.0-beta.3.
• Core, Identity, and Azure Storage for C++ version 1.0
• This release marks the general availability for Core, Identity, and Azure Storage.
• To get started and view samples, view the README on the Azure SDK for C++ repo.
• Quickstarts and documentation are being updated at Microsoft Docs.
• Key Vault Administration, Certificates, Keys and Secrets.
• Key Vault Administration is a new library that allows for role-based access control (RBAC), and backup and restore operations for Managed HSM.
• Key Vault Keys added functionality:
• Support for Managed HSM.
• Cryptography clients now support executing all operations locally if given a JsonWebKey.
• Support for creating and importing symmetric keys for Managed HSM.
• RSA keys now support providing a public exponent.

#azure sdk #azure #azure-sdk #javascript #python #release #sdk