skip to Main Content

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


  1. 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.

    Login or Signup to reply.
  2. This could be due to a variety of reasons.
    Please, provide us with more details.

    • Maybe it takes a long time for postgresql to start?
    • What operating system are you using?
    • What third-party packages are you using?
    • Did you tried to remove :z from the docker-compose?
    • Did you tried to run django without third-party packages?
    • Did you tried to do some profiling, e.g. using line-profiler?
    • Did you tried to monitor your processes inside the container? Or, in general, to find which process load CPU?

    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).

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search