We added a setting to configure the number of DelayedJob workers, defaulting
to two, and use that when we fire up the monitor.  Using two workers is a
reasonable default for finding problems caused by actual concurrency in
delayed work, without overloading too much systems with only a single core.

Also, update documentation to recommend that this is tuned to one worker per
core, which is the optimal saturation for long term use.  (At least, in the
current CPU-dominated use we make of them.  If we get I/O bound later we might
need to increase that.)

Reviewed-By: Matt Robinson <[email protected]>
---
 README.markdown                    |    4 ++++
 config/initializers/delayed_job.rb |    2 +-
 config/settings.yml.example        |    4 ++++
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/README.markdown b/README.markdown
index 599bec7..4b724db 100644
--- a/README.markdown
+++ b/README.markdown
@@ -132,6 +132,9 @@ Installation
 
             rake db:migrate db:test:prepare
 
+6.  Adjust the `delayed_job_workers` setting in `settings.yml`.  You should 
set this to the number of worker processes you want for background jobs.  We 
recommend one per CPU core in your system, but will work correctly with one or 
more.
+
+
 Ownership and permission requirements
 -------------------------------------
 
@@ -360,6 +363,7 @@ Performance
 
 The Puppet Dashboard slows down as it manages more data. Here are ways to make 
it run faster, from easiest to hardest:
 
+*  Tune `delayed_job_workers` to have one worker per CPU core on your system.
 *  Optimize your database by running `rake RAILS_ENV=production 
db:raw:optimize` from your Puppet Dashboard directory, this will reorganize and 
reanalyze your database for faster queries.
 *  Run the application in `production` mode, e.g. by running `./script/server 
-e production`. The default `development` mode is significantly slower because 
it doesn't cache and logs more details.
 *  Run the application using multiple processes to handle more concurrent 
requests. You can use Phusion Passenger, or clusters of Thin or Unicorn servers 
to serve multiple concurrent requests.
diff --git a/config/initializers/delayed_job.rb 
b/config/initializers/delayed_job.rb
index d8f54e2..737f7c7 100644
--- a/config/initializers/delayed_job.rb
+++ b/config/initializers/delayed_job.rb
@@ -6,7 +6,7 @@ Delayed::Worker.max_attempts = 3
 
 def start_delayed_job
   Thread.new do
-    `#{Rails.root}/script/delayed_job --pid-dir=#{DELAYED_JOB_PID_PATH} -p 
dashboard -m start`
+    `#{Rails.root}/script/delayed_job --pid-dir=#{DELAYED_JOB_PID_PATH} -p 
dashboard -n #{SETTINGS.delayed_job_workers || 2} -m start`
   end
 end
 
diff --git a/config/settings.yml.example b/config/settings.yml.example
index fbbed1d..1f8945a 100644
--- a/config/settings.yml.example
+++ b/config/settings.yml.example
@@ -76,4 +76,8 @@ disable_legacy_report_upload_url: false
 
 # Disables the UI and controller actions for editing nodes, classes, groups 
and reports.  Report submission is still allowed
 enable_read_only_mode: false
+
+# Delayed job worker process count - we recommend one per core on your system
+delayed_job_workers: 2
+
 #===[ fin ]=============================================================
-- 
1.7.5.4

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to