Expose more gunicorn options

[rumbin]

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if any
• I have reproduced the issue with at least the latest released version of superset
• I have checked the issue tracker for the same issue and I haven't found one similar

Superset version

0.15.4

Expected results

Passing more gunicorn settings is possible, either via superset runserver options or by using a config file.

Actual results

Only a few command options are available, some are even hardcoded.
This is the invocation command surrently used:

 cmd = (
            "gunicorn "
            "-w {workers} "
            "--timeout {timeout} "
            "-b {address}:{port} "
            "--limit-request-line 0 "
            "--limit-request-field_size 0 "
            "superset:app").format(**locals())

Steps to reproduce

Try passing gunicorn options like worker_class, threads, graceful_timeout or keepalive as command options to superset runserver.

Background info

For testing purpose, I modified the invocation command as follows:

 cmd = (
            "gunicorn "
            "-w {workers} "
            "--timeout {timeout} "
            "-b {address}:{port} "
            "--limit-request-line 0 "
            "--limit-request-field_size 0 "
            "-k gevent "
            "--threads 2 "
            "--graceful-timeout 30 "
            "--keep-alive 5 "
            "superset:app").format(**locals())

This way, my long-running queries dropped to 1/4th of the original duration.
Update 2017-02-05: Disregard this statement. In further tests, the default worker_class "sync" led to comparable results. It may boil down to training effects on the DB.

Now I'm looking for a way to pass the additional options in a clean way which will survive future superset upgrades.

[xrmx]

You have to double check that all the libraries are gevent safe, if something block then everything blocks.

[rumbin]

My example configuration was just meant to demonstrate that it would be rather useful to allow for specifying further gunicorn option to the superset runserver command.

In my eyes, a clean and very flexible approach would be a command line option for specifying a gunicorn config file.

@xrmx Thanks for pointing out that there might be incompatibilities. I was not aware of this. However, I actually don't even know a suitable approach of how to double check if the libraries are gevent safe. As corrected in my initial post, further benchmarks did not confirm significant performance benefits.
However, the gunicorn documentation recommends asynchronous worker types for applications that perform outgoing requests which take an undefined amount of time. I quickly tested gevent, gthread and gaiohttp and didn't encounter any issues so far.
I'm not experienced enough to judge, if the gunicorn recommendation is applicable to superset and if an issue should be filed for at least evaluating the pros and cons.

[mistercrunch]

@rumbin I'm open to exposing more in the CLI's subcommand if you want to submit a PR, though keep in mind that anyone can just issue their own gunicorn command if there are shortcomings in the Superset CLI's "shortcut" to gunicorn.