Configuring uWSGI for Production: The defaults are all wrong

Peter Sperl

Best Practice Distributed Systems Microservices Web Servers and MicroFWs (Flask/Tornado/Nginx/...) failures/mistakes

See in schedule

Two years ago, we began migrating from a proprietary service framework to a WSGI-compliant one. We chose uWSGI as our host because of its performance and feature set. But, while powerful, uWSGI's defaults are driven by backward compatibility and are not ideal for new deployments. Powerful features can be overlooked due to the sheer magnitude of its feature set and spotty documentation. As we've scaled up the number of services hosted by uWSGI over the last year, we've had to tweak our standard configuration.

In this talk, we'll present the base uWSGI configuration we use as a starting point for all services, as well as some tips to avoid known gotchas and provide a base level of defensiveness and high reliability. This base configuration makes use of several "no-cost" uWSGI features that help protect services from common, yet difficult to prevent issues -- some of which we discovered the hard way. We'll also talk about some programmatic uWSGI features which can be leveraged to improve reliability and improve outage response.

Some of the topics we'll cover include:
- Mitigating memory leaks
- Mitigating stuck, hung, or infinitely looping processes
- Preventing misconfigurations
- Preventing wasted development effort
- Improving outage response

Type: Talk (30 mins); Python level: Beginner; Domain level: Beginner