So it turned out my problem was in permission setting / checking.  I have
very fine-grained permissions for my app, and it was causing significant
overhead to the admin rendering process.  I'll look at Stephen's changes,
but some simple stuff on my side got the rendering times down to about what
other people on here are seeing.  Thanks to everyone for your help!

-- Jeff

On Wed, Oct 15, 2014 at 9:53 AM, Josh Cartmell <[email protected]> wrote:

> Would this mean that you could now only add custom page types using the
> top drop down?
>
> On Tue, Oct 14, 2014 at 10:13 PM, Stephen McDonald <[email protected]> wrote:
>
>> That's awesome advice Alex.
>>
>> I took it a bit further and ripped out more template logic, here's my
>> resulting admin template which renders my 1,400 or so pages in roughly 25%
>> of the time:
>>
>> https://gist.github.com/stephenmcd/87a3af5c9a3c66a6c716
>>
>> - Removed all permission setting/checking
>> - Removed iterating through all the page types and hard-coded the list of
>> these (still containing the page_id variable)
>> - Removed all use of {% url %} template tag, hard-coding admin urls (this
>> is a huge gain)
>> - Removed all use of {% static %} template tag, hard-coding paths to
>> static assests
>> - Removed cycling through CSS classes (I'm not even sure these are used
>> anymore)
>>
>>
>> On Wed, Oct 15, 2014 at 12:43 PM, Alexander Hill <[email protected]>
>> wrote:
>>
>>> I've run up against slow page admin rendering too, but nothing as
>>> extreme as 90 seconds – more like what Stephen is reporting, under ten
>>> seconds. I have a hierarchy with a little over a thousand pages, and I
>>> think the maximum depth is five.
>>>
>>> I found a lot of time was spent rendering
>>> templates/pages/menus/admin.html, specifically ascertaining permissions and
>>> building the list of models for the "Add..." menu. The majority of my pages
>>> are of one type that should only have that same type as children, and
>>> everyone should be able to add them, so I've overridden that template to
>>> just render a link instead of a drop down "Add..." menu which always adds
>>> that page type, instead of iterating over the list of models and checking
>>> permissions for each.
>>>
>>> That cuts down my rendering time by about half.
>>>
>>> Unfortunately Django templates ARE slow, and rendering a thousand of
>>> them nested is never going to be quick. That said, the times you're seeing
>>> are extreme and I can't think what would cause that in normal operation, so
>>> you probably will need to do some profiling...there is a Django template
>>> timings plugin for the Django debug toolbar which might help you:
>>> https://github.com/orf/django-debug-toolbar-template-timings
>>>
>>> Alex
>>>
>>> On Wednesday, 15 October 2014 00:46:27 UTC+8, Jefferson Heard wrote:
>>>>
>>>> Stephen, thanks.  Would a flatter hierarchy affect things much?  It's
>>>> not so much the render time as the processing time.  I'm getting to 504
>>>> timeouts on the server. I'm running in AWS, with an Amazon postgres and a
>>>> medium instance running the web application.  I suppose a profiling tool
>>>> *is* the next step, but I wondered if anyone else had run into this.
>>>>
>>>> On Mon, Oct 13, 2014 at 3:55 PM, Stephen McDonald <[email protected]>
>>>> wrote:
>>>>
>>>>> I don't know of one, but I'll just counter one anecdote with another.
>>>>>
>>>>> I generated 1463 pages evenly spread (11 primary pages, each with 11
>>>>> children, which each have 11 children), and on my macbook air the admin
>>>>> interface takes about 6 seconds to render, the front-end which renders a
>>>>> full tree as well as some limited trees takes about 3 seconds.
>>>>>
>>>>> 90 seconds on your machine vs < 10 seconds on a consumer grade laptop
>>>>> seems unreasonable. What type of machine are you running on?
>>>>>
>>>>> You might also like to dig into some profiling tools, like
>>>>> django-debug-toolbar and pycallgraph, but be warned adding these will
>>>>> certainly make things slower, so don't be deceived.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 14, 2014 at 2:16 AM, Jeff Heard <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Is there a mod that dynamically loads or paginates the pages section
>>>>>> in the admin?  I have 1559 pages and I always get a 504 timeout on
>>>>>> rendering.  When I don’t, it still takes like a minute and a half to 
>>>>>> render
>>>>>> the pages admin menu...
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Mezzanine Users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Stephen McDonald
>>>>> http://jupo.org
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Mezzanine Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mezzanine Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Stephen McDonald
>> http://jupo.org
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to