add nginx+gunicorn/uWSGI conf for better performence

[auvipy]

No description provided.

[sheppard]

Sure, this would be good to have. We'll probably want to rename the [projectname].conf to apache2.conf to avoid confusion.

[auvipy]

yup

[paolodina]

Hi, this nginx.conf template works in my setup (nginx+gunicorn). Minimal docs is included at the top. Anyone checking, please report if it works or not.

[sheppard]

Thanks, this looks like good start and I'll try it out when I get a chance. Feel free to start a pull request to make merging easier. A couple of other things to do would be to rename the included apache config to apache2.conf, and then update the docs (see wq/wq#13).

If someone with more nginx/gunicorn experience wants to take a look at this that would be great.

[chlarsen]

Dear All,
I followed the instructions, was able to install wq on OpenBSD without problems with the latest fix (thanks, Andrew!), but get the following, if I issue the following, using the above template:

[wq] ghs# bin/gunicorn --chdir /usr/local/wq/db/ -b 127.0.0.1:8000 wsgi.py
[2018-05-23 07:39:13 +0300] [22480] [INFO] Starting gunicorn 19.8.1
[2018-05-23 07:39:13 +0300] [22480] [INFO] Listening at: http://127.0.0.1:8000 (22480)
[2018-05-23 07:39:13 +0300] [22480] [INFO] Using worker: sync
[2018-05-23 07:39:13 +0300] [41889] [INFO] Booting worker with pid: 41889
[2018-05-23 07:39:13 +0300] [41889] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/workers/base.py", line 129, in init_process
    self.load_wsgi()
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/workers/base.py", line 138, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 52, in load
    return self.load_wsgiapp()
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 41, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/usr/local/wq/lib/python3.6/site-packages/gunicorn/util.py", line 350, in import_app
    __import__(module)
ModuleNotFoundError: No module named 'wsgi'

I did not have any luck with uWSGI, either, same problem of not finding a wsgi app.
Am I missing something silly?
Thanks a lot for your help!
Chris

[chlarsen]

Little update: I know that the above issue must be somewhere related to my lack of familiarity with Django, though I got gunicorn and uwsgi going without any issues with Mezzanine and such. The reason, why I am interested, no: keen, on a lightweight solution is that we plan to deploy lowish-spec machines in countries at current risk of the evolving Ebola outbreak, where such optimisations translate into real cost and power savings. Therefore, sorry for my pushing (I know I have not the slightest "right" to do so!), but any pointers would be absolutely terrific, while I am reading up on Django again....
A huge "Thank you"!
C.

[sheppard]

I haven't worked with gunicorn, but it looks like you are missing the project name (should be projectname.wsgi, which is a Python module path that resolves to projectname/wsgi.py). That said, if you planning on running the whole wq stack on each machine, you might be able to get by with just using Django's built in ./manage.py runserver. nginx/Apache/etc. are more important when you have multiple web/mobile clients submitting data to a centralized public web server.

[chlarsen]

Dear Andrew, Thank you for the lead, let me look into it. I will keep you updated. Hugely appreciated. Have a nice weekend! Chris

…

On May 24, 2018 8:47:31 PM UTC, "S. Andrew Sheppard" ***@***.***> wrote: I haven't worked with gunicorn, but it looks like you are missing the project name (should be projectname.wsgi, which is a Python module path that resolves to projectname/wsgi.py). That said, if you planning on running the whole wq stack on each machine, you might be able to get by with just using Django's built in ./manage.py runserver. nginx/Apache/etc. are more important when you have multiple web/mobile clients submitting data to a centralized public web server. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #11 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.