gunicorn
django-debug-toolbar
Our great sponsors
gunicorn | django-debug-toolbar | |
---|---|---|
17 | 19 | |
9,504 | 7,903 | |
- | 0.7% | |
8.0 | 8.4 | |
2 days ago | 2 days ago | |
Python | Python | |
GNU General Public License v3.0 or later | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gunicorn
-
Nginx Unit – Universal web app server
I'm hoping so – gunicorn has a long-open pull request that would fix `--reuse-port`, which currently does nothing
https://github.com/benoitc/gunicorn/pull/2938
- SynchronousOnlyOperation from celery task using gevent execution pool on django orm
-
Deploying Django when using python-socketio
However, I'm curious about the best way to deploy, specifically with regard to WSGI. I've tried using the raw eventlet WSGI server (`eventlet.wsgi.server(eventlet.listen(("", 8000)), application)`). I then start it with `python manage.py runserver`. This has worked okay, but I'm unsure about how scalable it is. It seems like the standard stack is Django + Gunicorn + NGINX. Based on `python-socketio` documentation, this should be possible. I tried django + eventlet + gunicorn, but it seems like gunicorn a) [doesn't play nice with eventlet](https://github.com/benoitc/gunicorn/pull/2581) and b) only supports one worker. Gevent + Gunicorn doesn't have this bug, but still only supports one worker. Also, I'm not sure how actively maintained gevent is. So I'm not sure how scalable either Gunicorn + eventlet or Gunicorn + geventlet is as a WSGI server. So I'm not sure if Gunicorn is my best bet, or if it's too limited.
- The Django ecosystem is not so good
-
3 cool project ideas for Python programmers
For building your API, I recommend using the Flask library. It is very beginner-friendly, and you will be able to build a simple API in a matter of minutes! Keep in mind that, for a more serious project, you should definitely use something like gunicorn to run you API as a production server.
-
Django 4.1 Released
Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it.
https://github.com/benoitc/gunicorn/pull/2820
-
Serverless Templates for AWS and Python
The cool thing is that you can easily migrate your WSGI- application such as Flask, Django, or Gunicorn to AWS.
-
Scope of database threads + connections + sessions
Yeah, that's kind of the impression I was getting. I stumbled across a github issue for gunicorn along these lines.
-
Running Django with Gunicorn - Best Practice
Taking a glimpse at gunicorn's code it looks like they pretty much all do the same: 2. seems to be creating a wsgi app using django's internals, and 3. uses 2.
django-debug-toolbar
-
Setting up Django in a Better Way in 5 Minutes and Understanding How It Works
The reason behind this splitting is that we can safely use packages and related settings only where we need. For example, this starter kit has the package django-debug-toolbar. This is only intended for your development environment and not for your production. This can be very risky if used in production because if your Django project encounters errors, all the debug info will be shown to the user which is a severe security risk. Similarly, for tracking errors in production, we're using Sentry which is not needed in our local environment since we already have django-debug-toolbar. For keeping these settings file separate so that they don't conflict with each other, the settings file is split for serving different environments.
-
Difficulty with foreignkey connecting to main object
django-debug-toolbar: https://github.com/jazzband/django-debug-toolbar
-
The Django ecosystem is not so good
https://github.com/jazzband/django-debug-toolbar/issues?q=is%3Aopen+is%3Aissue+label%3ABug
- Slow performance on AJAX queries in Django 4
-
is it alright to use raw sql and not the ORM if my queries are slow?
https://github.com/jazzband/django-debug-toolbar Allows you to check which sql queries are being run on your app. See if they are optimized first.
-
How to improve django template performance?
Perhaps try the django-debug-toolbar. It might be able to tell you what is causing the slow load time.
-
How do I determine where to cache?
I would start with https://github.com/jazzband/django-debug-toolbar and figure out what causes the slowness.
-
Improve your Django query with bulk_create 👋
-> The debugging above from django-debug-toolbar
-
Django Debug Toolbar
Documentation, including installation and configuration instructions, is available at https://django-debug-toolbar.readthedocs.io/.
- Five Easy to Miss PostgreSQL Query Performance Bottlenecks
What are some alternatives?
waitress - Waitress - A WSGI server for Python 3
django-silk - Silky smooth profiling for Django
Werkzeug - The comprehensive WSGI web application library.
django-ninja - 💨 Fast, Async-ready, Openapi, type hints based framework for building APIs
bjoern - A screamingly fast Python 2/3 WSGI server written in C.
ipdb - Integration of IPython pdb
uwsgi - Official uWSGI docs, examples, tutorials, tips and tricks
pudb - Full-screen console debugger for Python
meinheld - Meinheld is a high performance asynchronous WSGI Web Server (based on picoev)
django-devserver - A drop-in replacement for Django's runserver.
hypercorn - Hypercorn is an ASGI and WSGI Server based on Hyper libraries and inspired by Gunicorn.
wdb - An improbable web debugger through WebSockets