Reputation: 3990
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 :
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
Upvotes: 2
Views: 912
Reputation: 3990
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.
Upvotes: 0
Reputation: 1211
There could be several causes for high response time, to isolate the issue. Kindly try these steps:
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.
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".
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)
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.
Troubleshooting intermittent outbound connection errors in Azure App Service - (to isolate port exhaustion).
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)
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.
Upvotes: 0