I’m running a dockerized Django application: only Django + Postgres on local.
When I start the application and go to any localhost URL, it takes up to 3-4 minutes to respond. Then it works as expected, with 100-200 ms response time.
- There are no heavy processes running and it behaves like that regardless of the URL, it could be admin, swagger or any other.
- It noticeably loads my CPU for the duration of that "freeze". I have had this issue for quite some time on a very old machine and thought it’s just because it’s old, but I’ve just tested it on a brand new one and it has the same issue, so it’s not the hardware.
- Deploy and URL/API tests are not affected by this and work with no freezes.
- Executing any commands with
docker-compose exec
or~run
works as expected despite the app not responding to any HTTP requests.
PS: I can add thread dump or any other logs if necessary, I really have no clue as to where to look for the source of the problem.
Here’s my .yml
file contents, in case it might be the culprit:
version: '3'
volumes:
backend_local_postgres_data: {}
backend_local_postgres_data_backups: {}
services:
django: &django
build:
context: .
dockerfile: ./compose/local/django/Dockerfile
image: backend_local_django
container_name: backend_local_django
depends_on:
- postgres
volumes:
- .:/app:z
env_file:
- ./.envs/.local/.django
- ./.envs/.local/.postgres
ports:
- "8000:8000"
command: /start
postgres:
build:
context: .
dockerfile: ./compose/production/postgres/Dockerfile
image: backend_production_postgres
container_name: backend_local_postgres
volumes:
- backend_local_postgres_data:/var/lib/postgresql/data:Z
- backend_local_postgres_data_backups:/backups:z
env_file:
- ./.envs/.local/.postgres
Application launch logs, as requested in a couple answers:
(venv) docker-compose -f local.yml up
[+] Running 1/1
- Network backend_default Created 0.6s
[+] Running 3/34T19:42:41+01:00" level=warning msg="mount of type `volume` should not define `bind` option"
- Network backed_default Created 0.6s
- Container backend_local_postgres Created 0.1s
- Container backend_local_django Created 0.1s
Attaching to backend_local_django, backend_local_postgres
|
| PostgreSQL Database directory appears to contain a database; Skipping initialization
|
| 2023-02-04 18:42:42.783 UTC [1] LOG: starting PostgreSQL 14.6 (Debian 14.6-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
| 2023-02-04 18:42:42.783 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
| 2023-02-04 18:42:42.783 UTC [1] LOG: listening on IPv6 address "::", port 5432
| 2023-02-04 18:42:42.792 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
| 2023-02-04 18:42:42.804 UTC [27] LOG: database system was shut down at 2023-02-01 11:55:22 UTC
| 2023-02-04 18:42:42.814 UTC [1] LOG: database system is ready to accept connections
| PostgreSQL is available
| Operations to perform:
| Apply all migrations: account, admin, auth, authtoken, constructor, contenttypes, django_celery_beat, sessions, sites, socialaccount, users
| Running migrations:
| No migrations to apply.
| WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
| * Running on all addresses (0.0.0.0)
| * Running on http://127.0.0.1:8000
| * Running on http://172.18.0.3:8000
| Press CTRL+C to quit
| * Restarting with watchdog (inotify)
| Performing system checks...
|
| System check identified no issues (0 silenced).
|
| Django version 4.0.8, using settings 'config.settings.local'
| Development server is running at http://0.0.0.0:8000/
| Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
| Quit the server with CONTROL-C.
| * Debugger is active!
| * Debugger PIN: 130-235-671
In case the issue might be connected to one of the libraries I’m using, here’s my requirements.txt
as well:
pytz==2022.6 # https://github.com/stub42/pytz
python-slugify==7.0.0 # https://github.com/un33k/python-slugify
Pillow==9.3.0 # https://github.com/python-pillow/Pillow
argon2-cffi==21.3.0 # https://github.com/hynek/argon2_cffi
redis==4.3.5 # https://github.com/redis/redis-py
hiredis==2.0.0 # https://github.com/redis/hiredis-py
celery==5.2.7 # pyup: < 6.0 # https://github.com/celery/celery
django-celery-beat==2.4.0 # https://github.com/celery/django-celery-beat
flower==1.2.0 # https://github.com/mher/flower
# Django
# ------------------------------------------------------------------------------
django==4.0.8 # pyup: < 4.1 # https://www.djangoproject.com/
django-environ==0.9.0 # https://github.com/joke2k/django-environ
django-model-utils==4.3.1 # https://github.com/jazzband/django-model-utils
django-allauth==0.51.0 # https://github.com/pennersr/django-allauth
django-crispy-forms==1.14.0 # https://github.com/django-crispy-forms/django-crispy-forms
crispy-bootstrap5==0.7 # https://github.com/django-crispy-forms/crispy-bootstrap5
django-redis==5.2.0 # https://github.com/jazzband/django-redis
# Django REST Framework
djangorestframework==3.14.0 # https://github.com/encode/django-rest-framework
django-cors-headers==3.13.0 # https://github.com/adamchainz/django-cors-headers
djangorestframework-simplejwt==5.2.2
drf-yasg==1.21.4
-r base.txt
Werkzeug[watchdog]==2.2.2 # https://github.com/pallets/werkzeug
ipdb==0.13.9 # https://github.com/gotcha/ipdb
psycopg2-binary==2.9.5 # https://github.com/psycopg/psycopg2
watchfiles==0.18.1 # https://github.com/samuelcolvin/watchfiles
# Testing
# ------------------------------------------------------------------------------
mypy==0.982 # https://github.com/python/mypy
django-stubs==1.12.0 # https://github.com/typeddjango/django-stubs
pytest==7.2.0 # https://github.com/pytest-dev/pytest
pytest-sugar==0.9.6 # https://github.com/Frozenball/pytest-sugar
djangorestframework-stubs==1.7.0 # https://github.com/typeddjango/djangorestframework-stubs
# Documentation
# ------------------------------------------------------------------------------
sphinx==5.3.0 # https://github.com/sphinx-doc/sphinx
sphinx-autobuild==2021.3.14 # https://github.com/GaretJax/sphinx-autobuild
# Code quality
# ------------------------------------------------------------------------------
flake8==5.0.4 # https://github.com/PyCQA/flake8
flake8-isort==5.0.3 # https://github.com/gforcada/flake8-isort
coverage==6.5.0 # https://github.com/nedbat/coveragepy
black==22.10.0 # https://github.com/psf/black
pylint-django==2.5.3 # https://github.com/PyCQA/pylint-django
pylint-celery==0.3 # https://github.com/PyCQA/pylint-celery
pre-commit==2.20.0 # https://github.com/pre-commit/pre-commit
# Django
# ------------------------------------------------------------------------------
factory-boy==3.2.1 # https://github.com/FactoryBoy/factory_boy
django-debug-toolbar==3.7.0 # https://github.com/jazzband/django-debug-toolbar
django-extensions==3.2.1 # https://github.com/django-extensions/django-extensions
django-coverage-plugin==2.0.4 # https://github.com/nedbat/django_coverage_plugin
pytest-django==4.5.2 # https://github.com/pytest-dev/pytest-django
2
Answers
If you start the server and wait several minutes before visiting any pages, does it still take several minutes for that first page? It’s possible the containers are taking a long time to start for whatever reason. Figuring out if it is a long startup in general or something request specific could be a good spot to start.
This could be due to a variety of reasons.
Please, provide us with more details.
This slow initial response time is likely due to your application doing some time-consuming tasks.
The starting point in profiling could be the "-X importtime" option to the Python interpreter. This may help in identifying slow modules (if any).