Question 104198 in Azure Question posted in
The official documentation to get you started can be found here.

Django Rest Framework very slow on Azure

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

enter image description here

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

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 :

enter image description here
enter image description here

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
Tags:

4

Answers


  1. Chosen as BEST ANSWER
    0

    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.


  2. 0

    There are a number of issues which can impact performance like:

    • Network requests taking a long time
    • Application code or database
    • Queries being inefficient Application using high memory/CPU
    • Application crashing due to an exception

    To isolate the issue. You may try below troubleshooting steps:

    1. Observe and monitor application behavior
    2. Collect data
    3. Mitigate the issue

    Would suggest you to navigate to your web app in the Azure portal and select the ‘diagnose and solve’ blade of your web app> click on Linux web app Slow under popular troubleshooting tools, the information provided here would be helpful for fixing this.

    enter image description here

    Further you can follow to speed up for drf try removing the unwanted apps in INSTALLED_APPS and MIDDLEWARE this may help in boosting your django rest framework performance.

    Login or Signup to reply.
  3. 0

    Just to highlight that an App service always runs in an App Service plan. When you create an App Service plan in any region a set of compute resources is created for that plan in that region.

    Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan. Each App Service plan defines:

    • Operating System (Windows, Linux)
    • Region (West US, East US, etc.)
    • Number of VM instances
    • Size of VM instances (Small, Medium, Large)
    • Pricing tier (Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3, Isolated, IsolatedV2)

    As per diagnostic tool, its reflecting that there is Too many active container running per host and high load average, and its recommended to move some of your app to other app service plan and consider scaling out to reduce load.

    Suggest you to refer this detailed step by step guide on Move an app to another App Service plan

    Please note that you can move an app to another App Service plan, as long as the source plan and the target plan are in the same resource group and geographical region.

    For scaling out suggest you to follow detailed step mentioned in : Scale instance count manually or automatically you can choose to run your application on more than one instance.
    Scaling out not only provides you with more processing capability, but also gives you some amount of fault tolerance. If the process goes down on one instance, the other instances continue to serve requests. You can set the scaling to be Manual or Automatic.

    Further you may also consider Scale up as there is new PremiumV3 pricing tier gives you faster processors, SSD storage, and quadruple the memory-to-core ratio of the existing pricing tiers (double the PremiumV2 tier). With the performance advantage, you could save money by running your apps on fewer instances.

    Check this article on to learn how to create an app in PremiumV3 tier or scale up an app to PremiumV3 tier.

    More details:
    Azure App Service plan overview

    Update:

    Also suggest you to go to App Service Diagnostics and see as below:

    enter image description here

    enter image description here

    1. If Linux Zombie processes detected this may effect the performance and makes application slow. Zombie Process or defunct process is one which has completed execution but still exists in system process table. i.e, the parent process has not yet read the child processes exit status.

    2. Zombie processes can either be detected by looking at top or ps output.

    Recommended Action if Linux Zombie process detected:

    1. SSH into your app container by going to
      https://sitename.scm.azurewebsites.net.
    2. Use ps to check for any <defunct> processes. Sample below.

    ps -aux | grep -w defunct
    root 3300 0.0 0.0 0 0 pts/24 ZN+ 18:51 0:00 [newzombie]

    1. Use top to show any processes in a ‘Z’ state. Sample below (press ‘o’ and filter using ‘S=Z’)

    top – 19:02:22 up 28 days, 13:35, 26 users, load average: 0.39, 0.65,
    0.86
    Tasks: 66 total, 1 running, 64 sleeping, 0 stopped, 1 zombie
    %Cpu(s): 2.7 us, 2.0 sy, 1.0 ni, 93.9 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
    KiB Mem : 1975528 total, 123776 free, 1049580 used, 802172 buff/cache
    KiB Swap: 1910780 total, 769432 free, 1141348 used. 658264 avail Mem

      PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 3317 root      30  10       0      0      0 Z  0.0  0.0   0:00.00 newzombie
    1. Once the process is identified, try restarting the process or consider restarting your site.

    Look for if there is HTTP Server Errors as HTTP 500.0 error typically indicates an application code issue. An un-handled exception in the application code or an error in application is what typically causes this error.

    Login or Signup to reply.
  4. 0

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

    enter image description here

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

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

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

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

    enter image description here

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

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search