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

feat(helm): Added env variable SERVER_WORKER_AMOUNT #21236

Merged
merged 3 commits into from
Aug 30, 2022

Conversation

rathberm
Copy link
Contributor

SUMMARY

I added the environment variable SERVER_WORKER_AMOUNT to the helm values file. It is commented out so it won't affect any running instances. We had severe performance problems caused by superset workers timing out. This was solved and the general Superset performance was improved by increasing the Server Worker Amount. Although this variable can have a huge impact on performance it is never mentioned, neither in the docs nor in the helm chart.
The standard value of 1 is set in run-server.sh.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

Change the variable, at the start of the containers you can see the workers starting up in the logs.

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

@danielhass
Copy link

From my point of view I would also appreciate the consolidation of gunicorn related environment variables into a common prefix as some of them already start with GUNICORN_*. This makes the configuration interface more consistent and easier to read.

However this is a more breaking change as a switch from SERVER_WORKER_AMOUNT to e.g. GUNICORN_WORKER_AMOUNT might break existing settings and deployments.


# Increase the gunicorn worker amount, can improve performance drastically
# See: https://docs.gunicorn.org/en/stable/design.html#:~:text=Gunicorn%20should%20only%20need%204,workers%20to%20start%20off%20with.
# SERVER_WORKER_AMOUNT: 4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be great if you could add the rest of the variables: SERVER_THREADS_AMOUNT, GUNICORN_KEEPALIVE, WORKER_MAX_REQUESTS , WORKER_MAX_REQUESTS_JITTER, SERVER_LIMIT_REQUEST_LINE, SERVER_LIMIT_REQUEST_FIELD_SIZE

modify the link to just: https://docs.gunicorn.org/en/stable/design.html#how-many-workers

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find SERVER_WORKER_AMOUNT anywhere in the Gunicorn docs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@craig-rueda as you can see in run-server.sh the variable SERVER_WORKER_AMOUNT is introduced by Superset und used to set the flag --workers when starting gunicorn. It's not a gunicorn variable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dpgaspar I added the variables and a link to the general documentation where users can find the settings.

@dpgaspar
Copy link
Member

From my point of view I would also appreciate the consolidation of gunicorn related environment variables into a common prefix as some of them already start with GUNICORN_*. This makes the configuration interface more consistent and easier to read.

However this is a more breaking change as a switch from SERVER_WORKER_AMOUNT to e.g. GUNICORN_WORKER_AMOUNT might break existing settings and deployments.

Totally agree, this can probably be done without breaking anything

Copy link
Member

@dpgaspar dpgaspar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, would be great also if you could add a link to where these are used run-server.sh since their names are a bit confusing (optional)

@danielhass
Copy link

Totally agree, this can probably be done without breaking anything

@dpgaspar what would be your idea for implementing this without breaking the existing configuration interface? A change of all variables to a common GUNICORN_* prefix might break configurations that users currently applied via the old environment variables.

Offering backward compatibility for these options from my point of view would require a lot of logic checking for the different variants and defining a set of precedence rules for the different options.

What was your idea?

@dpgaspar
Copy link
Member

Totally agree, this can probably be done without breaking anything

@dpgaspar what would be your idea for implementing this without breaking the existing configuration interface? A change of all variables to a common GUNICORN_* prefix might break configurations that users currently applied via the old environment variables.

Offering backward compatibility for these options from my point of view would require a lot of logic checking for the different variants and defining a set of precedence rules for the different options.

What was your idea?

Could be DRYer but something similar to:

if [[ -z "${SERVER_WORKER_AMOUNT}" ]]; then
  GUNICORN_WORKERS=${GUNICORN_WORKERS:-1}
elif [[ -z "${GUNICORN_WORKERS}" ]]; then
  GUNICORN_WORKERS=${SERVER_WORKER_AMOUNT}
fi

echo ${GUNICORN_WORKERS}

?

@craig-rueda craig-rueda merged commit 05bdaf2 into apache:master Aug 30, 2022
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 2.1.0 and removed 🚢 2.1.3 labels Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/S 🚢 2.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants