James,
Thanks for the quick look, the tips and more. I am using Django 1.11 and
given your notes a huge suspect because:
1. This slow down is very recent
2. very recently I upgraded to 1.11 specifically because I needed a
subquery on one view
Rolling back to 1.10 is an option for testing, but I need that subquery.
I will see how much hassle it is to unwind to 1.10 and check the page
render time on that one page.
Onto your other suggestions, I will follow them through, but further notes:
1. This is a CreateView that is rendering in 20s so there's no object
data per se, except for the widgets for the related models (drop
downs). But a quick check reveals (Just loading the page and waiting
20s for it arrive - nuts on a high specced dev machine with dev
server and no load) it has 5 drop downs as following sizes:
1. 1 value (hardly a drop down ;-)
2. 3 values (also hardly a drop down)
3. 39 values (a little more, but the day 39 objects slows a server
down without surprise is, well in 1965 with punchcards ;-)
4. 44 values (ditto)
5. 44 values (same related model as previous one).
2. I intend to move to DAL (django-autocomplete-light widgets for these
anyhow, because while those list sizes are small a production site
can go into hundreds, thousands, 10s of thousands ... over time. And
this page render time aside, drop downs are just not practical ...
3. pprint.py bugs me too, as I searched my code base for references in
case I was using it but failed to find one. Which does not rule it
out, just makes it unlikely at present. Yes, a good next step is to
load pprint.py set a breakpoint in it, run and check the stack to
see how I got there and why. If it's from my code, awesome, I can
fix it ;-), if Django is going it, at least one step closer to
understanding.
Regards,
Bernd
James Schneider wrote:
On Mon, May 22, 2017 at 10:12 PM, Bernd Wechner
<bernd.wech...@gmail.com <mailto:bernd.wech...@gmail.com>> wrote:
James,
If you have the fortitude and kind heart to look at it, sure the
code base (just checked in) is here:
https://github.com/bernd-wechner/CoGs
<https://github.com/bernd-wechner/CoGs>
<snip>
That's quite a code repo. Bravo. I did poke through it a bit, thank
you for the extensive comments and properly formatted code. Helped
tremendously.
However, nothing jumped out as the culprit. Given that the render* and
other output functions seem to be suspect, I'd do the following:
* You didn't mention your specific Django version. If 1.11, try
backing it off to 1.10, and if on 1.10, try upgrading to 1.11. The
reason being is that there were some significant changes to the
template rendering system in 1.11 that may be causing excessive calls.
o
https://docs.djangoproject.com/en/1.11/releases/1.11/#template-based-widget-rendering
* Determine how many objects and related objects you are dealing
with during the slow page rendering. Your queries may be quick,
but coercing a large number of objects into Django models and then
coercing them again in to form elements may be problematic.
* Determine where the culprit code in the templates is (or if it is
template rendering at fault). Try attaching the view to a blank
template and see if you get the same result. If so, start adding
pieces of the template back in until you find the problem area.
The view/template in question renders several forms. Commenting
them out may help track down which form is at fault. There could
possibly be a circular dependency somewhere causing the form
rendering process to go crazy as well (ie Session ties to League,
Location, and Game, but League ties together Location and Game).
Given the other optimizations for related models you've added,
there might be a loop somewhere. This also feels a bit de-normalized.
* The pprint.py thing is really bugging me, as there shouldn't be
any reason to ever call that. Might be useful to do an interactive
debug to step through and see what is causing those calls, or if
they are red herrings from the profiling process, etc.
Give that a shot and let me know.
-James
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXnuomTDLD61WEard8-a%3DSRQkZUkHYn6Y_m3UkWVV6w_g%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXnuomTDLD61WEard8-a%3DSRQkZUkHYn6Y_m3UkWVV6w_g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/fb1b9477-cdc2-1f3d-d0cd-069ad2311469%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
