uWSGI - Swiss army knife for your Python web apps
Download as PPTX, PDF•4 likes•3,181 views
uWSGI is a full-stack tool for building hosting services that acts as an application server for Python web apps using the WSGI specification. It provides a pluggable architecture, versatility, high performance, low resource usage, and reliability. Configuration options are extensive and allow for processes, threads, reloading, monitoring and more. Proper configuration and testing is required to optimize performance for production deployments.
uWSGI - Swiss army knife for your Python web apps
- 1. uWSGI Swiss army knife for your Python web apps TOMISLAV RAŠETA @traseta
- 2. me scribbling and doodling on *IX operating systems for 10+ years working as sysadmin/DevOps with a hint of networking tools of the trade nginx apache tomcat (ugh!) python php java (ugh!) postgresql mysql memcached redis mongo not a developer, sorry :)
- 3. before we begin know your environment server specs (cores, memory, bandwidth) virtualenv or global know your application database pooling agents and latencies python version requirements (!) Linux kernel tunables limits.conf (file descriptors) ipv4.tcp_tw_reuse (not recycle) kernel.shmmax ipv4.ip_local_port_range
- 4. what it is full stack for building hosting services pluggable architecture mostly used as application server for Python apps using WSGI “WSGI is the Web Server Gateway Interface. It is a specification that describes how web server communicates with web applications, and how web applications can be chained together to process one request.” rules versatility performance low-resource usage reliability developed by @unbit (Italy) awesome docs
- 5. installation PyPI most recent versions, maintained by devs pip install uwsgi use virtualenv when possible watch out for dependencies - check what you actually need, the compile errors/warnings are very descriptive distro packed versions are *always* outdated “from source” - please avoid :)
- 6. configuration choice of xml, ini, command-line arguments etc. read the docs carefully don’t reinvent the wheel "Please, turn on your brain and try to adapt shown configs to your needs, or invent new ones."
- 7. configuration example (xml), start from ve <uwsgi> <chdir>/home/user/ve/app</chdir> <wsgi-file>project.wsgi</wsgi-file> <uid>user</uid> <gid>user</gid> <uwsgi-socket>/home/user/uwsgi/uwsgi.sock</uwsgi-socket> <chmod-socket>600</chmod-socket> <pidfile>/home/user/uwsgi/uwsgi.pid</pidfile> <stats>/home/user/uwsgi/uwsgistats.sock</stats> <buffer-size>8192</buffer-size> <post-buffering>4096</post-buffering> <memory-report/> <daemonize>/home/user/uwsgi/daemon.log</daemonize> <reload-mercy>20</reload-mercy> <max-requests>500</max-requests> <max-worker-lifetime>86400</max-worker-lifetime> <socket-timeout>5</socket-timeout> <disable-logging/> <reload-on-rss>256</reload-on-rss> <touch-reload>/home/user/ve/app/project.wsgi</touch-reload> <enable-threads/> <threads>1</threads> <processes>100</processes> <single-interpreter/> <vacuum/> </uwsgi>
- 8. start it up activate ve uwsgi --xmlconfig /home/user/uwsgi/uwsgi.xml configure and start nginx location / { include uwsgi_params; uwsgi_pass unix:/home/wmaster/uwsgi/uwsgi.sock; } ta-daa! tip: socket based pass doesn’t consume server TCP port usage = less SYSCPU time on your server; you can use TCP but check your kernel tunables before! (tcp_tw_reuse, ip_local_port_range tip2: you can also use mod_uwsgi and apache
- 9. cool conf stuff (I) harakiri (timeout) every request is timestamped If a master process finds a worker with a timestamp running more than specified timeout it will kill it logs: “F*CK !!! i must kill myself (pid: 9984 app_id: 0)” reload-on-rss gracefully reload a worker after the memory consumption of the worker goes above this threshold you’re alive even if you have a nasty memory leak max-requests - gracefully reload a process after n requests max-worker-lifetime – gracefully reload a process after n seconds logs: “...The work of process PID is done. Seeya!"
- 10. cool conf stuff (II) reload-mercy wait for n seconds for worker to die during reload/shutdown touch-reload reload your app by touching a single file (your main project file) attach-daemon attach-daemon = memcached -p 11911 -u user when uWSGI is stopped or reloaded, memcahed is destroyed smart-attach-daemon smart-attach-daemon = /tmp/memcached.pid memcached -p 11911 -d -P /tmp/memcached.pid -u user memcached survives
- 11. production settings processes “There is no magic rule for setting the number of processes or threads to use. It is very much application and system dependent. Simple math like processes = 2 * cpucores will not be enough. You need to experiment with various setups and be prepared to constantly monitor your apps.” threads “If you need threads, remember to enable them with enable-threads.” start with: processes = n, threads = 1 multi-threading should be thoroughly tested! (debugging is very hard) rule of thumb for avoiding OOM when using threads=1: available memory = process n * reload-on-rss value suspect everything, test everything, log everything
- 12. performance testing get URLs which your applications deliver run siege / apachebench while keeping your eye on monitoring/logging hardware is cheap buy more memory get a faster CPU scaling up is always easier than optimizing your app
- 13. production deployment keep a single project file touch it when updating art of graceful reloading https://github.com/unbit/uwsgi- docs/blob/master/articles/TheArtOfGracefulReloading.rst “Some applications or frameworks (like Django) may load the vast majority of their code only at the first request.” – causes timeouts if you have high requests/second rate keep multiple application servers with reverse-proxy (or LB in front) update one server at the time, warm it up with siege/ab
- 14. monitor all the things! New Relic uwsgitop Sentry Cacti dstat, iostat, htop etc.
- 15. uwsgitop <stats>/home/user/uwsgi/uwsgistats.sock</stats> pip install uwsgitop uwsgitop /home/user/uwsgi/uwsgistats.sock
- 16. New Relic pip install newrelic uwsgi start script newrelic-admin generate-config <LICENSE> newrelic.ini NEW_RELIC_CONFIG_FILE=/home/user/uwsgi/newrelic.ini export NEW_RELIC_CONFIG_FILE newrelic-admin run-program uwsgi --xmlconfig /home/user/uwsgi/uwsgi.xml tip: newrelic is sometimes buggy (memory leak) tip!
- 17. things not mentioned emperor router metrics (snmp, statsd, alarms etc.) signal framework caching framework autostarting (supervisor, upstart) …
- 18. other WSGI app servers mod_wsgi Python version hell Green Unicorn (Gunicorn) Passenger (requires Ruby even if you don’t use it) etc.
- 19. conclusion very active project with a fast release cycle bunch of configuration options modular awesome docs mailing list support FTW!