uWSGI – Understanding uwsgi_socket_keepalive Effect

I saw your post yesterday, just searching for an answer for exactly the same issue. Finally, today I reached the root of the problem.

I suppose you specify the chdir in your .ini config file as the directory where your project is located. I mean that if for example your project is 'myproject' and you have it in '/var/www/myproject' directory, you specify '/var/www' as the chdir.

So, the path for all internal resources is not well defined, and Python interpereter (may be you are using Django?) does not reach them. Ok, I will explain how a solution works in a Django project. For example, suppose that you have an app inside your project called 'app1'; in your views module you are calling for a forms defined in your forms module; you will be doing this like that:

from app1.forms import *

okay? Well, the thing is that the path is not well defined for uwsgi. You should now define this like that:

from myproject.app.forms import *

and you will see that everything is working now. No more 502 Bad Gateway errors will appear for you :)

Yes, I know that is not very elegant to add 'myproject.' to every internal resource calling. So, you can simply add this to your 'settings.py' file:

sys.path.append('/var/www/myproject/')

Substitute '/var/www/' for the path where your project is located on your machine. With this tiny solution, every started working for me :)

I hope my comment helps you.

Cheers, Jose

You don't.

That's the simple answer, anyway -- you don't need it. uWSGI is itself a capable server.

However, other servers like nginx have been around longer and are (probably, anyway) more secure, as well as having additional features not supported by uWSGI -- for example, improved handling of static resources (via any combination of Expires or E-Tag headers, gzip compression, pre-compressed gzip, etc.) that can significantly reduce server and network load; additionally, a server like nginx in front of your Django application can implement caching of your dynamic content as well, further helping to reduce server load, and even helping to facilitate the use of a CDN (which normally don't do well with dynamic content). You could even go further and have nginx on a completely separate server, reverse proxying requests for dynamic content to a load balanced cluster of application servers while handling the static content itself.

For example, my blog (while it is WordPress, it does have nginx in front of it) is tuned to cache posts for 24 hours, and to cache index pages for 5 minutes; while I don't see enough traffic for that to really matter most of the time, it helps my tiny little VPS weather the occasional surge that might otherwise knock it down -- such as the big surge of traffic when one of my articles got picked up by a Twitterer with many thousands of followers, many of whom re-tweeted it to their thousands of followers.

If I had been running a "bare" uWSGI server (and assuming it had been a Django site, rather than WordPress), it might have stood up to it just fine -- or it might have crashed and burned, costing me in missed visitors. Having nginx in front of it to handle that load can really help.

All that being said, if you're just running a little site that won't see a lot of traffic, there's no real need for nginx or anything else -- just use uWSGI on its own if that's what you want to do. On the other hand, if you'll see a lot of traffic... well, you still might want uWSGI, but you should at least consider something in front of it to help with the load. Actually, you should really be load-testing different configurations with your finished site to determine what does work best for you under your expected load, and use whatever that ends up being.