Forem: Mohammad Karimi

Compilation steps in EF Core

Mohammad Karimi — Thu, 29 Feb 2024 18:16:05 +0000

In Entity Framework (EF) Core, the compilation phase is a crucial part of translating LINQ queries into SQL queries. The process involves the creation and execution of parameterized SQL queries based on the LINQ expressions. However, there are optimizations and features that can bypass or streamline this compilation process for improved performance.

let's delve into each phase in a bit more detail:

LINQ Expression Tree:
- Entity Framework Core starts its journey with LINQ queries expressed as expression trees, a representation of code as data. These trees capture the structure and logic of queries.
Parameter Extraction and Cache Key:
- Before executing a query, EF Core extracts parameters from the LINQ expression tree. These parameters are essential for creating a cache key, ensuring uniqueness for each distinct query.
Cache Check:
- EF Core checks its cache using the generated cache key. If a matching query and its result are found, this signifies that the query has been executed before. In such cases, EF Core can skip the compilation phase, directly utilizing the precompiled SQL and rapidly materializing objects.
Compilation Phase:
- In scenarios where no match is found in the cache, EF Core enters the compilation phase. During this stage, it transforms the LINQ expression tree into parameterized Transact-SQL (T-SQL) statements. This process involves mapping LINQ expressions to corresponding SQL constructs.
Execution and Materialization:
- With the compiled T-SQL in hand, EF Core executes the query against the underlying database. The result, typically a set of records, is then materialized into .NET objects or entities, aligning the relational data with the object-oriented model.
Cache Update:
- Following a successful execution, EF Core updates its cache by storing the compiled query and its result. This caching strategy enhances future query performances, as subsequent executions of the same query can directly benefit from the cached, precompiled SQL.

EF Compiled Query API:

Recognizing that certain queries are executed frequently, EF Core provides the CompiledQuery API as a performance optimization tool. Developers can explicitly compile queries, creating reusable query objects. These compiled queries can be stored and reused across multiple executions, eliminating the need for redundant compilation and enhancing overall system efficiency.

Advantages of Using Compiled Queries:

Performance: Compiled queries, whether managed by EF Core's caching mechanism or explicitly by developers, can significantly improve performance by reducing the overhead associated with repeated query compilation.
Reusability: The ability to compile queries explicitly allows for their reuse across various parts of an application, promoting a more efficient and maintainable codebase.
Caching Benefits: Caching not only minimizes compilation time but also serves as a strategy for storing frequently accessed queries and their results, further enhancing overall application responsiveness.

Understanding these phases and features within EF Core's query compilation process provides developers with insights into optimizing database interactions for better performance and responsiveness in their applications.

Cross-Platform Diagnostic Tools for .NET Applications

Mohammad Karimi — Mon, 05 Feb 2024 12:24:23 +0000

Introduction
In the dynamic world of software development, understanding and monitoring the performance of your applications is crucial for delivering a seamless user experience. For .NET developers, having access to effective cross-platform diagnostic tools is invaluable. In this article, we'll take a closer look at three essential tools: dotnet-counters, dotnet-trace, and dotnet-dump.

dotnet-counters: Overview of Application State
One of the fundamental diagnostic tools for .NET applications is dotnet-counters. This tool provides developers with a comprehensive overview of the current state of a running application. It covers essential metrics and performance indicators, allowing developers to gauge the health and efficiency of their code in real-time. By utilizing dotnet-counters, developers can identify potential issues and bottlenecks, making it an invaluable tool for both development and production environments.

Installing and using dotnet-counters is a straightforward process. Follow these steps to get started:

Installation:

Ensure .NET SDK is Installed:
Before using dotnet-counters, make sure you have the .NET SDK installed on your machine. You can download it from the official Microsoft .NET website.
Verify Installation:
Open a terminal or command prompt and run the following command to verify that the .NET SDK is installed:

   dotnet --version

If the installation is successful, you should see the installed version of the .NET SDK.

Install the dotnet-counters Tool: Run the following command to install the dotnet-counters tool globally on your machine:

   dotnet tool install --global dotnet-counters

Verify Installation of dotnet-counters: Ensure that dotnet-counters is installed correctly by running:

   dotnet-counters --version

This should display the installed version of dotnet-counters.

Usage:

Run dotnet-counters: To use dotnet-counters to monitor the state of a running application, navigate to the directory containing your .NET application and run:

   dotnet-counters monitor

Specify Process ID (PID): If you know the Process ID (PID) of the running application, you can directly monitor that process using:

   dotnet-counters monitor --process-id <PID>

View Available Counters: To see a list of available counters for the monitored process, use:

   dotnet-counters list

Filter Counters: You can filter counters based on categories. For example, to monitor only CPU-related counters, use:

   dotnet-counters monitor --category cpu

Stop Monitoring: To stop monitoring, press Ctrl+C in the terminal or command prompt.

Additional Options:

--refresh-interval: Set the refresh interval for counter updates.
--format: Choose the output format (table, json, or csv).

Example:

dotnet-counters monitor --process-id 1234 --category cpu --refresh-interval 1s

This example monitors the CPU-related counters for the process with ID 1234, refreshing every second.

Keep in mind that dotnet-counters is a powerful tool, and you can customize its usage based on your specific monitoring needs. Adjust the parameters and options as necessary to gain insights into the application state effectively.

dotnet-trace: Detailed Performance and Event Monitoring
When a more in-depth analysis of performance and event monitoring is needed, dotnet-trace steps in. This diagnostic tool offers a detailed perspective on various aspects of application behavior. Developers can use dotnet-trace to track down specific events, understand the sequence of operations, and identify potential performance bottlenecks. This tool empowers developers to delve deeper into their codebase, making it an excellent choice for optimizing and fine-tuning application performance.

Here's a guide on how to install and use dotnet-trace for detailed performance and event monitoring:

Installation:

Ensure .NET SDK is Installed:
Before using dotnet-trace, make sure you have the .NET SDK installed on your machine. You can download it from the official Microsoft .NET website.
Verify Installation:
Open a terminal or command prompt and run the following command to verify that the .NET SDK is installed:

   dotnet --version

If the installation is successful, you should see the installed version of the .NET SDK.

Install the dotnet-trace Tool: Run the following command to install the dotnet-trace tool globally on your machine:

   dotnet tool install --global dotnet-trace

Verify Installation of dotnet-trace: Ensure that dotnet-trace is installed correctly by running:

   dotnet-trace --version

This should display the installed version of dotnet-trace.

Usage:

Run dotnet-trace: To use dotnet-trace for performance and event monitoring, navigate to the directory containing your .NET application and run:

   dotnet-trace collect

Specify Process ID (PID): If you know the Process ID (PID) of the running application, you can directly collect traces for that process using:

   dotnet-trace collect --process-id <PID>

View Available Providers: To see a list of available event providers for tracing, use:

   dotnet-trace list-providers

Filter Events: You can filter events based on providers and keywords. For example, to trace only events related to garbage collection, use:

   dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime --events GC

Stop Tracing: To stop collecting traces, press Ctrl+C in the terminal or command prompt.

Additional Options:

--duration: Set the duration for trace collection.
--output: Specify the output file for the collected traces.
--format: Choose the output format (nettrace or speedscope).

Example:

dotnet-trace collect --process-id 1234 --providers Microsoft-Windows-DotNETRuntime --events GC --output trace.nettrace

This example collects traces related to garbage collection for the process with ID 1234 and saves the output to a file named trace.nettrace.

Adjust the parameters and options based on your specific monitoring requirements, and explore the wealth of information that dotnet-trace provides for optimizing and fine-tuning your .NET applications.

dotnet-dump: Memory Insights On Demand
Memory-related issues are a common challenge in software development. dotnet-dump is a powerful diagnostic tool that allows developers to obtain a memory dump on demand or after a crash. This capability is invaluable for troubleshooting memory leaks, analyzing memory usage patterns, and identifying potential areas for improvement. By providing insights into the application's memory state, dotnet-dump aids developers in optimizing resource utilization and enhancing overall application stability.

Here's a guide on how to install and use dotnet-dump to obtain a memory dump on demand or after a crash:

Installation:

Ensure .NET SDK is Installed:
Before using dotnet-dump, make sure you have the .NET SDK installed on your machine. You can download it from the official Microsoft .NET website.
Verify Installation:
Open a terminal or command prompt and run the following command to verify that the .NET SDK is installed:

   dotnet --version

If the installation is successful, you should see the installed version of the .NET SDK.

Install the dotnet-dump Tool: Run the following command to install the dotnet-dump tool globally on your machine:

   dotnet tool install --global dotnet-dump

Verify Installation of dotnet-dump: Ensure that dotnet-dump is installed correctly by running:

   dotnet-dump --version

This should display the installed version of dotnet-dump.

Usage:

Capture a Memory Dump: To capture a memory dump of a running .NET process, navigate to the directory containing your .NET application and run:

   dotnet-dump collect --process-id <PID>

Capture a Memory Dump on Crash: If your application crashes, you can automatically capture a memory dump by using:

   dotnet-dump collect --process-id <PID> --trigger-once

Analyze a Memory Dump: To analyze a previously captured memory dump, run:

   dotnet-dump analyze <DumpFilePath>

List Loaded Assemblies: To view the loaded assemblies in a memory dump, use:

   dotnet-dump ps

Quit dotnet-dump: To exit the dotnet-dump interactive mode, type q and press Enter.

Additional Options:

--output: Specify the output directory for the collected memory dump.
--timeout: Set the timeout for capturing a memory dump on crash.

Example:

dotnet-dump collect --process-id 1234 --output ./dumps

This example captures a memory dump for the process with ID 1234 and saves it to the ./dumps directory.

Feel free to customize the parameters and options based on your specific requirements. dotnet-dump is a powerful tool for diagnosing memory-related issues and gaining insights into the state of your .NET applications.

Conclusion
In the realm of .NET development, having access to cross-platform diagnostic tools is a game-changer. The trio of dotnet-counters, dotnet-trace, and dotnet-dump equips developers with the necessary instruments to monitor, analyze, and optimize their applications effectively. Whether it's gaining an overview of application state, delving into detailed performance metrics, or troubleshooting memory-related issues, these tools play a pivotal role in ensuring the robustness and efficiency of .NET applications. Incorporating these diagnostic tools into your development workflow will undoubtedly contribute to a more streamlined and reliable software development process.

Top Tools for Load and Stress Testing

Mohammad Karimi — Fri, 02 Feb 2024 09:35:32 +0000

I think that Writing an article on load and stress testing tools can be a great resource for developers, testers, and anyone involved in ensuring the performance and scalability of software applications. Here's a more detailed exploration of the mentioned tools to help you:

Apache JMeter
- Overview: Apache JMeter is a versatile and widely used open-source tool for performance testing. It allows users to simulate a variety of scenarios and protocols, including HTTP, HTTPS, FTP, SOAP, and more.
- Features:
  - User-friendly GUI for test plan creation.
  - Extensive reporting and analysis capabilities.
  - Supports distributed testing for scalability.
LoadRunner (by Micro Focus):
- Overview: LoadRunner is a comprehensive commercial tool designed for performance testing. It has been a staple in the industry for many years and supports a wide range of protocols.
- Features:
  - Supports protocols such as HTTP, HTTPS, JDBC, and more.
  - Scenario-based testing with various load models.
  - Advanced reporting and analytics.
Gatling:
- Overview: Gatling is an open-source load testing tool that focuses on simplicity and scalability. It is scriptable in Scala and provides real-time reporting.
- Features:
  - Supports HTTP and WebSocket protocols.
  - Scenario-based testing with a user-friendly DSL (Domain-Specific Language).
  - Distributed testing capabilities.
K6:
- Overview: K6 is an open-source load testing tool written in Go. It is known for its ease of use and supports JavaScript-based scripting.
- Features:
  - Simple command-line interface.
  - Supports HTTP and WebSocket protocols.
  - Can be used for both performance and load testing.
Artillery:
- Overview: Artillery is an open-source and extensible load testing tool built on Node.js. It focuses on simplicity and flexibility, allowing users to define testing scenarios using YAML.
- Features:
  - Supports HTTP and WebSocket protocols.
  - YAML-based scripting for defining complex scenarios.
  - Real-time reporting during test execution.
Locust:
- Overview: Locust is an open-source load testing tool written in Python. It emphasizes ease of use and scalability, making it suitable for testing a wide range of applications.
- Features:
  - Scripted in Python, making it accessible for Python developers.
  - Supports HTTP and provides a clean web-based UI.
  - Distributed testing capabilities.
BlazeMeter:
- Overview: BlazeMeter is a commercial load testing service based on Apache JMeter. It offers a cloud-based platform for easily executing and managing performance tests.
- Features:
  - Integrates with Apache JMeter.
  - Provides cloud-based load testing services.
  - Real-time reporting and analytics.

When selecting a tool, consider factors such as your specific testing requirements, ease of use, scripting capabilities, and reporting features. It's also important to evaluate whether the tool aligns with your technology stack and the type of applications you are testing (web applications, APIs, etc.).

Simplifying API Calls with Refit in ASP.NET Core

Mohammad Karimi — Fri, 26 Jan 2024 15:13:31 +0000

Refit is a library in ASP.NET Core that simplifies the process of making HTTP requests to RESTful APIs. It allows you to define your API interfaces as C# interfaces and then use them as if they were local methods. This makes it easier to work with APIs in a type-safe manner. Here's a guide to help you get started on writing an article about using Refit in ASP.NET Core:

Start by introducing the challenges of making HTTP requests to APIs in a traditional way in ASP.NET Core. Mention the verbosity and boilerplate code involved in handling HTTP requests and responses.

What is Refit?
Briefly explain what Refit is and its main purpose. Emphasize that it simplifies the process of working with APIs by allowing developers to define API interfaces as C# interfaces.

Setting Up Refit

Install Refit Package Guide the readers through the process of installing the Refit NuGet package in an ASP.NET Core project.

dotnet add package Refit

Creating an API Interface
Show how to create an API interface using Refit. This involves defining methods that represent the different API endpoints.

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Body { get; set; }
}

public interface IApiClient
{
    [Get("/api/posts")]
    Task<List<Post>> GetPosts();

    [Post("/api/posts")]
    Task<Post> CreatePost([Body] Post newPost);
}

Integrating Refit into ASP.NET Core Registering Refit in Dependency Injection:

Explain how to register Refit in the ASP.NET Core dependency injection container. This is usually done in the Startup.cs file.

services.AddRefitClient<IApiClient>()
    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://api.example.com"));

Using Refit in Controllers or Services
Show examples of how to use the Refit interface in controllers or services. Emphasize the simplicity and type-safety that Refit brings.

public class PostsController : ControllerBase
{
    private readonly IApiClient _apiClient;

    public PostsController(IApiClient apiClient)
    {
        _apiClient = apiClient;
    }

    public async Task<IActionResult> GetPosts()
    {
        var posts = await _apiClient.GetPosts();
        return Ok(posts);
    }

    // ...
}

Handling Authentication
Explain how Refit handles authentication, whether it's through headers, tokens, or other authentication mechanisms.

Advanced Features

Request and Response Logging
Show how to enable request and response logging for debugging purposes.

services.AddRefitClient<IApiClient>()
    .AddHttpMessageHandler<YourLoggingHandler>();

Customizing Requests
Discuss how to customize requests using Refit attributes and options.

Conclusion
Summarize the benefits of using Refit in ASP.NET Core. Highlight the reduction in boilerplate code, improved type safety, and increased developer productivity when working with APIs.

Safe guarding Sensitive Data in ASP.NET Core with Secret Manager

Mohammad Karimi — Sun, 21 Jan 2024 17:00:19 +0000

Introduction:
In the realm of ASP.NET Core development, the need to manage sensitive data, such as application secrets, is paramount. To address this concern, the Secret Manager tool provides a secure and convenient solution, enabling developers to store and access sensitive information during the development phase without compromising security. In this article, we will delve into the workings of the Secret Manager tool, its setup, and how to seamlessly integrate it into your ASP.NET Core projects.

Understanding the Secret Manager Tool:
The Secret Manager tool operates by concealing the intricate details of where and how sensitive values are stored, allowing developers to utilize its capabilities without delving into implementation specifics. These app secrets, which should never be included in source control, are stored in a JSON file located in the local machine's user profile folder.

Windows File System Path:

%APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secrets.json

Enabling Secret Storage:
To enable the Secret Manager tool, the dotnet user-secrets init command is utilized, Or Click-Right on your project in Visual Studio and select Manage User Secrets Item.

dotnet user-secrets init

This command adds a UserSecretsId element within the project file's PropertyGroup. The UserSecretsId is a unique identifier associated with the project, and it is used to link secrets to the specific project.

Sample Project File (XML):

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <UserSecretsId>79a3edd0-2092-40a2-a04d-dcb46d5ca9ed</UserSecretsId>
</PropertyGroup>

Setting a Secret:
Once the Secret Manager is initialized, secrets can be defined and associated with the project's UserSecretsId. For example, using the .NET CLI:

dotnet user-secrets set "ConnectionStrings:ApplicationDbContext" "..."

Accessing a Secret
To access a secret within your ASP.NET Core project, follow these steps:

Register the User Secrets Configuration Source
The User Secrets Configuration Provider registers the necessary configuration source with the .NET Configuration API.
Read the Secret via the Configuration API
Utilize the Configuration API to retrieve the secret securely within your application.

Conclusion
The Secret Manager tool in ASP.NET Core provides a robust solution for managing sensitive information during the development phase. By seamlessly integrating with the .NET Configuration API, it ensures a secure and organized approach to handling app secrets. As developers, embracing tools like Secret Manager not only enhances security but also streamlines the development process by separating sensitive data from version-controlled source code.

Let's dive a bit deeper into each step of the MediatR architecture

Mohammad Karimi — Tue, 16 Jan 2024 07:11:42 +0000

In MediatR architecture, each task is represented by a Request, sent to the corresponding Handler by the framework. However, MediatR acts like a pipeline, not directly passing the Request to the Handler.

Instead, it goes through one or more middlewares, called Pipeline Behaviors, in three steps:

1. Pre-Processing:
In the Pre-Processing step, the incoming Request is handed over to the Pre-processor. This is like the front door of the MediatR pipeline, where the Request is checked, validated, and possibly transformed before proceeding further.
The Pre-processor can perform tasks such as ensuring the Request is in the right format, validating user input, or making any necessary adjustments to the Request data.

2. Next Step:
Assuming the Pre-Processing step succeeds, the pipeline moves to the Next Step. Here, a delegate decides what comes next in the pipeline.
This could be another middleware instance, adding another layer of processing, or the final destination, which is the Handler responsible for carrying out the core logic related to the Request.
Think of it as passing the baton in a relay race; the Request smoothly moves to the next phase of processing.

3. Post-Processing:
After the core logic (handled by the Handler) is executed, the pipeline reaches the Post-Processing step. This is the last stage before the result is sent back to the client.
In Post-Processing, actions like logging the outcome, making final adjustments to the Response, or handling errors are performed.
It's the place where you tie up loose ends, ensuring that everything is in order before the processed data is sent back to the client.

Important Notes:
If there's an issue during the Pre-Processing (e.g., validation failure), the process immediately goes back, bypassing the Next and Post steps. This quick exit ensures that only valid Requests proceed through the entire pipeline.
On the other hand, when everything goes smoothly, the logic is executed, and the Post-Processing step is not extensively used for validation-related tasks. It focuses more on actions needed after the Request is validated and processed.
In essence, the MediatR pipeline is a carefully orchestrated sequence of steps, each playing a vital role in ensuring efficient and organized handling of Requests, from validation to execution and finalization.

How DbContext pooling works!

Mohammad Karimi — Mon, 15 Jan 2024 12:24:45 +0000

If you are developing a high-performance ASP.NET Core application using Entity Framework Core, you may want to consider using DbContext pooling to reduce the overhead of creating and disposing of DbContext instances. DbContext pooling is a feature that allows EF Core to reuse the same context instance across requests, instead of creating a new one every time. This can improve performance by avoiding the cost of setting up various internal services and objects that are necessary for DbContext to work.

In this blog post, I will explain how DbContext pooling works, how to enable it in your application, and what are some of the benefits and limitations of this feature.

How DbContext pooling works!

DbContext pooling works by reusing the same context instance across requests; this means that it’s effectively registered as a Singleton, and the same instance is reused across multiple requests (or DI scopes). However, unlike a normal Singleton, EF Core resets the state of the context before returning it to the pool, so that it behaves as if it was a new instance. This includes clearing any tracked entities, resetting any configuration options, and disposing of any internal resources.

To enable DbContext pooling, you must replace the AddDbContext method with AddDbContextPool in your ConfigureServices method. For example:

services.AddDbContextPool<BlogContext>(options => options.UseSqlServer(Configuration.GetConnectionString("BlogContext")));

You can also specify the maximum size of the pool by passing a second parameter to AddDbContextPool. The default size is 1024, which means that EF Core will keep up to 1024 context instances in the pool. If the pool size is exceeded, EF Core will return to creating new instances on demand.

Benefits and limitations of DbContext pooling

The main benefit of DbContext pooling is that it can improve performance by reducing the overhead of creating and disposing of DbContext instances. This can be especially noticeable in scenarios where you have many concurrent requests that use DbContext for short-lived operations. According to Microsoft’s documentation, DbContext pooling can reduce request latency by up to 50% compared to non-pooling.

However, DbContext pooling also has some limitations that you need to be aware of. First of all, you need to make sure that your context does not hold any state that should not be shared across requests. For example, you should not use any static fields or properties in your context class, or store any data in the HttpContext.Items collection. You should also avoid using any custom services or objects that are not thread-safe or disposable in your context constructor or OnConfiguring method.

Another limitation is that DbContext pooling does not work well with some features of EF Core that rely on modifying the context state at runtime. For example, you cannot use ChangeTracker.QueryTrackingBehavior or ChangeTracker.AutoDetectChangesEnabled properties to change the tracking behavior of your context after it has been created. You also cannot use a Database.SetCommandTimeout or Database.SetConnectionString methods to change the database connection settings of your context after it has been created. If you need to use these features, you should either disable DbContext pooling or use a separate non-pooled context for those operations.

Finally, DbContext pooling may not have a significant impact on performance if your application does not use DbContext extensively, or if your database operations are long-running or complex. In these cases, the cost of creating and disposing of DbContext instances may be negligible compared to the cost of executing queries or saving changes. You should always measure the performance of your application before and after enabling DbContext pooling to see if it makes a difference for your scenario.

dotnet #entityframework #EF