Slow Performance Issue with Django Admin in Production Environment
Hello, I need help because the Django admin is very slow when accessing an app. With the same database of less than 8000 records, it takes 8.60 seconds on the server and only 90 ms locally. I tried adding workers on the server, but it doesn't improve. I also tested it from very close to the server (from Miami), so I don't think it's latency. I have the Pro plan.
25 Replies
Project ID:
60937526-0f38-463c-a9c3-319f6b9e53dd60937526-0f38-463c-a9c3-319f6b9e53dd
where is your database hosted?
I have tested from US West (Oregon, USA) and also from US East (Virginia, USA).
okay so the database is on railway?
Yes, it is in railway
is your database and django app both in us east?
Yes, both the database and Django app are hosted in the US East
is your django app connecting to the database via the private network?
Yes, the Django app is connecting to the database via the private network
whats your middleware stack?
My middleware stack configuration in the Django settings file is as follows:
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
"whitenoise.middleware.WhiteNoiseMiddleware",
'django.contrib.sessions.middleware.SessionMiddleware',
"corsheaders.middleware.CorsMiddleware",
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.locale.LocaleMiddleware',
'auditlog.middleware.AuditlogMiddleware',
]
looks fine, what is debug set to when on railway?
DEBUG is set to False
whats your start command when you run locally, and your start command that railway runs?
local:
python manage.py runserver
railway:
I've tried many production setups, but currently, this is what I'm using "python manage.py migrate && python manage.py collectstatic --noinput && gunicorn -k gevent --workers=8 gym.wsgi"
already using gevent, that was what i was going to ask you to try next
any idea what might be going on?
at this moment no, but i do know that this would not be a platform issue
there is some kind of misconfiguration somewhere
is there any way to debug or trace where it's coming from?
you would need to implement some kind of highly verbose logging for that
have you tried other worker classes?
yes, I've experimented with different worker classes, but the performance issue persists
im stumped, that just leaves process of elimination, remove bits of code until the issue goes away, not the most elegant solution, but it can work
thank you very much for the suggestion and help, I will keep trying
please update me if you find anyting!