Django Rest Framework very slow on Azure

Question

I had migrated from Heroku to Microsft Azure, and the speed is really very slow, my App service is having the following specs OS (linux):

P1V2
210 total ACU
3.5 GB memory
Dv2-Series compute equivalent

then when it comes to my Azure Database for PostgreSQL flexible server, the following are the specs OS (linux):

General Purpose (2-64 vCores) - Balanced configuration for most common workloads

This is my response time of 15 sec because of Redis cache, sometimes it goes up to 30 sec or beyond :

Am sure all these Specs are higher than the default Heroku specs it used to give, but why is my Django project very slow when it comes to the response time of the API requests?

ADDITION :

• I am using a container registry which connects to the App service wherever there's an auto-deployment.
• I also fixed the n + 1 issue on the endpoints.
• Always on is on, I read several posts like this one.

UPDATE :

I have an ps and top via bash with Kudu, but I don't seem to see any zomibe processes, I also searched with S=Z after pressing 'o', but I didn't find any, below are the screenshots :

top - 16:31:58 up 1 day,  1:47,  1 user,  load average: 0.36, 0.62, 0.48
Tasks:   7 total,   1 running,   6 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.9 us,  4.6 sy,  2.2 ni, 89.5 id,  2.4 wa,  0.0 hi,  0.5 si,  0.0 st
MiB Mem :  13993.7 total,   2266.7 free,   1967.4 used,   9759.6 buff/cache
MiB Swap:   2048.0 total,   2032.2 free,     15.8 used.  11719.2 avail Mem 

Answer 1

There could be several causes for high response time, to isolate the issue. Kindly try these steps:

1. If it’s not done already, turn on Always On feature. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time.

2. On the App Service App, in the left navigation, click on Diagnose and solve problems – Checkout the tile for “Diagnostic Tools” > “Availability and Performance” & "Best Practices".

3. Update the CPU utilization as 75% for scale-out condition or 25% for scale-in condition as test and see if that makes any difference (to avoid flapping condition/I understand you have already analyzed CPU usage)

4. Isolate/Avoiding the outbound TCP limits is easier to solve, as the limits are set by the size of your worker. You can see the limits in Sandbox Cross VM Numerical Limits - TCP Connections- - To avoid outbound TCP limits, you can either increase the size of your workers, or scale out horizontally.

5. Troubleshooting intermittent outbound connection errors in Azure App Service - (to isolate port exhaustion).

6. f there are multiple Apps under a single App Service Plan, distribute the apps across multiple app service plans to obtain additional compute levels (to isolate the issue further/shared more details on this in the ‘comment’ section below)

7. Review the logs to fetch more details on this issue.

Note: Linux is currently the recommended option for running Python apps in App Service and I believe you’re leveraging the App Service Linux flavor.

Answer 2

After an engagement with the Microsoft team, the issue was that My Azure flexible server and App service were in different regions, one was in North South Africa and the other was in East US. So after ensuring all are in the same region, the issue was resolved.

Secondly, I had a field which had both text and images(base 64),I was using Django summernote, it provides a WYSIWYG experience, so it can store by default all the images and text together in the same field, so I optimized it, now the speed is super fast.