Que vs delayed_job

Overview

delayed_job

Stacks53

Followers65

Votes6

GitHub Stars4.8K

Forks952

Que

Stacks16

Followers20

Votes0

Que vs delayed_job: What are the differences?

Introduction

Que and delayed_job are both popular job processing libraries in Ruby on Rails applications. While they serve similar purposes, there are key differences between the two that developers should be aware of when choosing which one to use in their projects.

Scalability: Que uses a PostgreSQL database for its job storage, allowing for scalable job processing capabilities that can handle high volumes of jobs efficiently. On the other hand, delayed_job relies on the application's own database to store jobs, which may not be as optimized for handling large numbers of jobs.
Concurrency: Que is designed to efficiently handle multiple concurrent job processes by leveraging the PostgreSQL advisory lock feature, enabling better performance in environments with high concurrency requirements. In contrast, delayed_job processes jobs sequentially, which can lead to bottlenecks and decreased performance in highly concurrent scenarios.
Error Handling: Que provides robust error handling capabilities, allowing developers to easily track and manage job failures through its built-in error tracking features. delayed_job, on the other hand, may require more manual intervention to handle job failures effectively, potentially leading to higher maintenance overhead for handling errors.
Scheduling: Que offers more advanced job scheduling features, such as support for recurring jobs and job prioritization, making it suitable for more complex job processing requirements. delayed_job, while capable of basic job scheduling, may not offer the same level of flexibility and functionality when it comes to advanced scheduling needs.
Performance: Que is known for its performance optimizations, including efficient job processing algorithms and database interactions, that can lead to better overall performance and scalability compared to delayed_job. Developers working on applications with demanding performance requirements may benefit from Que's performance advantages over delayed_job.
Active Maintenance: Que is actively maintained and updated by its contributors, ensuring that it receives regular bug fixes, feature updates, and compatibility enhancements to keep up with the evolving Rails ecosystem. delayed_job, while still used in many projects, may not receive the same level of active maintenance and updates, potentially leading to compatibility issues and outdated features in the long run.

In Summary, Que offers scalability, concurrency, error handling, scheduling capabilities, performance optimizations, and active maintenance advantages over delayed_job in Ruby on Rails applications.

Share your Stack

Help developers discover the tools you use. Get visibility for your team's tech choices and contribute to the community's knowledge.

View Docs

CLI (Node.js)

Manual

Detailed Comparison

delayed_job	Que
Delayed_job (or DJ) encapsulates the common pattern of asynchronously executing longer tasks in the background. It is a direct extraction from Shopify where the job table is responsible for a multitude of core tasks.	Que is a high-performance alternative to DelayedJob or QueueClassic that improves the reliability of your application by protecting your jobs with the same ACID guarantees as the rest of your data.
-	Concurrency; Efficiency; Safety;Transactional Control;Atomic Backups;Fewer Dependencies; Security
Statistics
GitHub Stars 4.8K	GitHub Stars -
GitHub Forks 952	GitHub Forks -
Stacks 53	Stacks 16
Followers 65	Followers 20
Votes 6	Votes 0
Pros & Cons
Pros 3 Easy to get started 2 Reliable 1 Doesn't require Redis	No community feedback yet

What are some alternatives to delayed_job, Que?

Sidekiq

Sidekiq uses threads to handle many jobs at the same time in the same process. It does not require Rails but will integrate tightly with Rails 3/4 to make background processing dead simple.

Beanstalkd

Beanstalks's interface is generic, but was originally designed for reducing the latency of page views in high-volume web applications by running time-consuming tasks asynchronously.

Hangfire

It is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline. It supports all kind of background tasks – short-running and long-running, CPU intensive and I/O intensive, one shot and recurrent.

Resque

Background jobs can be any Ruby class or module that responds to perform. Your existing classes can easily be converted to background jobs or you can create new classes specifically to do work. Or, you can do both.

Faktory

Redis -> Sidekiq == Faktory -> Faktory. Faktory is a server daemon which provides a simple API to produce and consume background jobs. Jobs are a small JSON hash with a few mandatory keys.

Kue

Kue is a feature rich priority job queue for node.js backed by redis. A key feature of Kue is its clean user-interface for viewing and managing queued, active, failed, and completed jobs.

Bull

The fastest, most reliable, Redis-based queue for Node. Carefully written for rock solid stability and atomicity.

Cron

Background-only application which launches and runs other applications, or opens documents, at specified dates and times.

PHP-FPM

It is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites. It includes Adaptive process spawning, Advanced process management with graceful stop/start, Emergency restart in case of accidental opcode cache destruction etc.

Goose

It is a simple, reliable & scalable background processing library for Clojure. It has a transparent design & cloud-native architecture.

Related Comparisons

Que vs delayed_job: What are the differences?

Introduction

Scalability: Que uses a PostgreSQL database for its job storage, allowing for scalable job processing capabilities that can handle high volumes of jobs efficiently. On the other hand, delayed_job relies on the application's own database to store jobs, which may not be as optimized for handling large numbers of jobs.
Concurrency: Que is designed to efficiently handle multiple concurrent job processes by leveraging the PostgreSQL advisory lock feature, enabling better performance in environments with high concurrency requirements. In contrast, delayed_job processes jobs sequentially, which can lead to bottlenecks and decreased performance in highly concurrent scenarios.
Error Handling: Que provides robust error handling capabilities, allowing developers to easily track and manage job failures through its built-in error tracking features. delayed_job, on the other hand, may require more manual intervention to handle job failures effectively, potentially leading to higher maintenance overhead for handling errors.
Scheduling: Que offers more advanced job scheduling features, such as support for recurring jobs and job prioritization, making it suitable for more complex job processing requirements. delayed_job, while capable of basic job scheduling, may not offer the same level of flexibility and functionality when it comes to advanced scheduling needs.
Performance: Que is known for its performance optimizations, including efficient job processing algorithms and database interactions, that can lead to better overall performance and scalability compared to delayed_job. Developers working on applications with demanding performance requirements may benefit from Que's performance advantages over delayed_job.
Active Maintenance: Que is actively maintained and updated by its contributors, ensuring that it receives regular bug fixes, feature updates, and compatibility enhancements to keep up with the evolving Rails ecosystem. delayed_job, while still used in many projects, may not receive the same level of active maintenance and updates, potentially leading to compatibility issues and outdated features in the long run.

In Summary, Que offers scalability, concurrency, error handling, scheduling capabilities, performance optimizations, and active maintenance advantages over delayed_job in Ruby on Rails applications.

Que vs delayed_job

Overview