Hangfire.Pro v2.2.1 and Hangfire.Pro Redis v2.5.3
Hangfire.Pro v2.2.1 and Hangfire.Pro Redis v2.5.3
Hangfire Pro is a proprietary software without an OSS license available. It consist of the following packages that provide additional features and don’t aim to replace packages or assemblies of the open-source version.
Hangfire.Pro
Hangfire.Pro.Redis
Hangfire.Pro.Redis.StrongName
Hangfire.Pro.PerformanceCounters
It includes:
- Hangfire.Pro.Redis.2.5.3.Symbols.nupkg
- Hangfire.Pro.2.2.1.nupkg
- Hangfire.Pro.2.2.1.Symbols.nupkg
- Hangfire.Pro.PerformanceCounters.2.2.1.nupkg
- Hangfire.Pro.PerformanceCounters.2.2.1.Symbols.nupkg
- Hangfire.Pro.Redis.2.5.3.nupkg
New Package :
Hangfire Throttling 1.0.0-beta1
Hangfire Pro is a set of extension packages that boost the performance and simplify the maintenance of background job processing in large applications. Hangfire Pro packages are available under paid subscriptions. After purchase, you receive binaries and access to the private repository on GitHub.
Atomic Background Job Creation
Batches allow you to create a bunch of background jobs atomically. This means that if there was an exception during the creation of background jobs, none of them will be processed. Consider you want to send 1000 emails to your clients, and they really want to receive these emails. Here is the old way.
But what if storage become unavailable on i == 500? 500 emails may be already sent, because worker threads will pick up and process jobs once they created. If you re-execute this code, some of your clients may receive annoying duplicates. So if you want to handle this correctly, you should write more code to track what emails were sent.
Chaining Batches
Continuations allow you to chain multiple batches together. They will be executed once all background jobs of a parent batch finished. Consider the previous example where you have 1000 emails to send. If you want to make final action after sending, just add a continuation.
So batches and batch continuations allow you to define workflows and configure what actions will be executed in parallel. This is very useful for heavy computational methods as they can be distributed to different machines.
Hangfire.Pro.Redis
Background Jobs Throughput
Hangfire Pro comes with Hangfire.Pro.Redis package that uses Redis server to persist background jobs and other data.
Redis is well known for its outstanding performance and here are the results of relative comparison between Hangfire.SqlServer and Hangfire.Redis storages.
Hangfire.Pro.PerformanceCounters
Performance Monitor
Hangfire.Pro.PerformanceCounters package allows Hangfire to publish its internal metrics to Windows Performance Counters – the standard way to monitor Windows applications and services.
So, you can use existing tools like Nagios, New Relic, Server Density and others to proactively monitor the health of your services.
The goal of this release is to resolve the timeout issues that appear in .NET Core 2.X applications. Such behavior was caused by networking implementation of SE.Redis, which posted Redis response processing logic to thread pool’s worker threads, instead of completion ports or custom threads, due to the lack of the corresponding API in netstandard1.X specification.
When all the worker threads were waiting on Redis’ responses, there were no threads to process them and unblock threads that initiated those requests. And CLR’s “hill climbing” algorithm, that adds new threads, was able to resolve the problem only if there were no further synchronous requests to Redis.
Added – NETStandard 2.0 support for StackExchange.Redis to process callbacks in completion port threads.
Changed – StackExchange.Redis is internalized now even in .NET Standard packages.
Changed – RedisTransaction.Commit now works even when underlying connection was changed.
Fixed – Timeout issues in .NET Core 2.0 applications caused by thread pool starvation.
Fixed – Hangfire.Pro.Redis.StrongName package isn’t required now.
When all the worker threads were waiting on Redis’ responses, there were no threads to process them and unblock threads that initiated those requests. And CLR’s “hill climbing” algorithm, that adds new threads, was able to resolve the problem only if there were no further synchronous requests to Redis.
Added – NETStandard 2.0 support for StackExchange.Redis to process callbacks in completion port threads.
Changed – StackExchange.Redis is internalized now even in .NET Standard packages.
Changed – RedisTransaction.Commit now works even when underlying connection was changed.
Fixed – Timeout issues in .NET Core 2.0 applications caused by thread pool starvation.
Fixed – Hangfire.Pro.Redis.StrongName package isn’t required now.
Only for V.I.P Warning! You are not allowed to view this text.