Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understanding Database Connections and Cron #1013

Closed
blumhardts opened this issue Jul 19, 2023 · 1 comment
Closed

Understanding Database Connections and Cron #1013

blumhardts opened this issue Jul 19, 2023 · 1 comment

Comments

@blumhardts
Copy link
Contributor

blumhardts commented Jul 19, 2023

The docs for database connections make the development setup clear. Below is my development configuration.

# config/database.yml

development:
  <<: *default
  database: myapp_development
  # Good Job runs in :async mode in development and requires a few extra
  # database connections.
  # See https://github.com/bensheldon/good_job#database-connections for
  # more information.
  # - the number of threads for the web server (default is 5)
  # - 1 connection per query pool thread (default pool thread size is 5)
  # - 1 connection dedicated to the scheduler, a.k.a. LISTEN/NOTIFY
  # - 2 connections for cron, if it's running
  pool: <%= ENV.fetch("RAILS_MAX_THREADS", 5).to_i +
    ENV.fetch("GOOD_JOB_MAX_THREADS", 5).to_i +
    1 +
    (if ENV["GOOD_JOB_ENABLE_CRON"] == "true" then 2 else 0 end) %>

Things are less clear in test and production.

In test, GoodJob runs in :inline mode. I assume, because there is no mention of the connections required, I can leave them at the following.

# config/database.yml

test:
  <<: *default
  database: myapp_test
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

In production, GoodJob runs in :external mode. I plan on having dedicated worker instances that process jobs, separate from my web servers, which are capable of enqueuing jobs.

  1. Does the "scheduler, a.k.a. LISTEN/NOTIFY" connection need to be accounted for on workers and web servers, or just workers?

  2. Do the 2 cron connections need to be accounted for on workers and web servers, or just workers?

  3. Can each of my worker processes have cron enabled? The docs seem to state it's okay to run it on all worker processes, but the example implies it should only be run on one worker:

    Cron-style jobs are run on every GoodJob process (e.g. CLI or async execution mode) when config.good_job.enable_cron = true.

    # config/environments/application.rb or a specific environment e.g. production.rb
    
    # Enable cron in this process; e.g. only run on the first Heroku worker process
    config.good_job.enable_cron = ENV['DYNO'] == 'worker.1' # or `true` or via $GOOD_JOB_ENABLE_CRON

So far, I have been operating on the assumption that the answers to these questions are:

  1. Just workers
  2. Just workers
  3. Yes

Please let me know if those assumptions are correct. After that, I would be happy to open a PR in an effort to make the documentation on these points clearer.

@bensheldon
Copy link
Owner

  1. Just workers
  2. Just workers
  3. Yes

Yes, your assumptions totally correct 💯

I'd love some help with the documentation. It's tough to try to be explanatory, without also making it seem like something doesn't work (For example, the example of configuring cron is like "you can do this!" but isn't intended to be should or must)

bensheldon pushed a commit that referenced this issue Jul 27, 2023
)

* Clarify database connections and recurring processes in README.md

See #1013 for more context.

* Fix typos, formatting

* Add in missing backtick

* Update wording

* Update wording
legendarydeveloper919 added a commit to legendarydeveloper919/good_job that referenced this issue Mar 15, 2024
…015)

* Clarify database connections and recurring processes in README.md

See bensheldon/good_job#1013 for more context.

* Fix typos, formatting

* Add in missing backtick

* Update wording

* Update wording
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants