6 ms·

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a

I've been trying ways to profile my django code on my dev server. Its using runserver and postgres on virtualbox (ubuntu in ubuntu) and takes 20s to display a page. This is not due to slow db queries, those are quick. strace says its making a huge number of calls to: futex(0xe9d550, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 I tried debug_toolbar, Silk, yet-another-django-profiler, these dont give me insight into where all that time is going and where those mutex calls are coming from. Would this help? Any other suggestions? Edit: Exact same code is hugely faster on a webserver in production. And its not the Vbox specs, i gave it lots of RAM and 4 CPUs.

jchw 9y ago
My guess would be the filesystem, especially if you're using Vbox Shared Folders (either directly or through Vagrant.) If you're on Mac or Linux, you can massively reduce the amount of filesystem overhead by using Docker (or Docker Compose) for local testing, since on Linux it'll get direct access to the FS and on Mac it will use the special osxfs driver. You can also try using nfs to mount your drives instead of vbox shared folders if you want a quick gain, but it will make hot reloading even less reliable. You may also want to be sure your settings are really the same. Does DEBUG=0 change anything? What cache backend are you using? Etc. Finally, if none of the above helps you can try a move of desperation: try to get the app working on your native OS with no container or VM layer.
- mooneater 9y ago
  Wow your suggestion really helped: Debug toolbar itself was causing this for some reason. How embarrassing. Thanks!
  - jchw 9y ago
    That is rather surprising, because I don't have the same issue with a pretty large production app. I wonder if there's a deeper underlying issue.
    - mooneater 9y ago
      Ok I upgraded toolbar from 1.7 to 1.8 and problem is gone :) There are a number of toolbar bugs at https://github.com/jazzband/django-debug-toolbar/issues/943 https://github.com/jazzband/django-debug-toolbar/issues/943 involving keywords "slow" and "hang", not sure which it was. But the meta-issue is, the profiling tools I used were not super helpful in discovering what the issue was.
deleted 9y ago
[deleted]
trashcan 9y ago
Have you tried the low tech way of adding debug log statements that print how long a function takes to run? Once you know what is slow it should be easier to troubleshoot. Also I would check to see if you have any DNS issues in your virtual environment.
- mooneater 9y ago
  I think I would need to sprinkle django internals with log statements. I would do that as a very last resort but I feel it should be possible to avoid. I did solve this by removing django debug toolbar though trial and error (and still not sure why it was doing that), but I never found a tool which would discover that problem.
cuu508 9y ago
runserver as in "manage.py runserver"? An issue I have hit a few times is when the app is making a request to itself, but runserver cannot serve requests concurrently. Say, browser loads request A and waits for response. While processing request A, the python code makes an internal request B and waits for response. This deadlocks because runserver will not start processing B before A has finished. Eventually request A times out, and if it was just some tracking call, the page appears to load, just after a long pause.
- mooneater 9y ago
  Interesting. Yes "manage.py runserver". In my case, I have been loading one page at a time using runserver.

jchw 9y ago

My guess would be the filesystem, especially if you're using Vbox Shared Folders (either directly or through Vagrant.) If you're on Mac or Linux, you can massively reduce the amount of filesystem overhead by using Docker (or Docker Compose) for local testing, since on Linux it'll get direct access to the FS and on Mac it will use the special osxfs driver. You can also try using nfs to mount your drives instead of vbox shared folders if you want a quick gain, but it will make hot reloading even less reliable. You may also want to be sure your settings are really the same. Does DEBUG=0 change anything? What cache backend are you using? Etc. Finally, if none of the above helps you can try a move of desperation: try to get the app working on your native OS with no container or VM layer.

mooneater 9y ago
Wow your suggestion really helped: Debug toolbar itself was causing this for some reason. How embarrassing. Thanks!
- jchw 9y ago
  That is rather surprising, because I don't have the same issue with a pretty large production app. I wonder if there's a deeper underlying issue.
  - mooneater 9y ago
    Ok I upgraded toolbar from 1.7 to 1.8 and problem is gone :) There are a number of toolbar bugs at https://github.com/jazzband/django-debug-toolbar/issues/943 https://github.com/jazzband/django-debug-toolbar/issues/943 involving keywords "slow" and "hang", not sure which it was. But the meta-issue is, the profiling tools I used were not super helpful in discovering what the issue was.

deleted 9y ago

[deleted]

trashcan 9y ago

Have you tried the low tech way of adding debug log statements that print how long a function takes to run? Once you know what is slow it should be easier to troubleshoot. Also I would check to see if you have any DNS issues in your virtual environment.

mooneater 9y ago
I think I would need to sprinkle django internals with log statements. I would do that as a very last resort but I feel it should be possible to avoid. I did solve this by removing django debug toolbar though trial and error (and still not sure why it was doing that), but I never found a tool which would discover that problem.

cuu508 9y ago

runserver as in "manage.py runserver"? An issue I have hit a few times is when the app is making a request to itself, but runserver cannot serve requests concurrently. Say, browser loads request A and waits for response. While processing request A, the python code makes an internal request B and waits for response. This deadlocks because runserver will not start processing B before A has finished. Eventually request A times out, and if it was just some tracking call, the page appears to load, just after a long pause.

mooneater 9y ago
Interesting. Yes "manage.py runserver". In my case, I have been loading one page at a time using runserver.