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

Peter Sperl

Bloomberg LP

I currently work at Bloomberg LP leading the Structured Products Applications group where I initiated the group's transition from monolithic software to horizontally scalable RESTful microservices.

I graduated from Carnegie Mellon University in 2004 with a BS in Electrical and Computer Engineering. I worked for two funded startups, a research institute, and a large tech company before spending the last 10 years at Bloomberg. I am the creator of projectM (