Re: Where is all the time going?

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.wechner@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

<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.
• 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+unsubscribe@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/CA%2Be%2BciXnuomTDLD61WEard8-a%3DSRQkZUkHYn6Y_m3UkWVV6w_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.