Measure improvements to load time, scalability of notifications UI [#1864768]

user/[uid]/notification-settings embeds 4 views in quicktabs to show the items that a user follows. This currently means rendering 4 separate views. None of those views have pagers and we can easily end up displaying over 1,000 items total as shown in this screenshot.

In my experience this page can take 7+ seconds to render (though I didn't specifically measure TTFB/page generation time).

commons follow ui

Comment	File	Size	Author
	commons_follow_ui.png	67.41 KB	ezra-g

Comments

Comment #1

ezra-g commented 12 December 2012 at 14:36

We may also be able to improve the performance of the count() on the tabs since it currently executes the same view twice.

Comment #2

msonnabaum commented 12 December 2012 at 20:17

I'm seeing 1500+ calls to entity_load. The call chain is roughly like so:

views_handler_field::advanced_render -> … -> flag_flag::access -> … -> flag_entity::_load_content -> entity_load

Hoping we can construct the view in a different way so this doesn't happen…

Comment #3

ezra-g commented 13 December 2012 at 00:26

Thanks, msonnabaum!

2 other conveniences to add while we're working on these views:

- Magic table headers unless we page the views
- Sort by flag created time rather than alpha.

Comment #4

ezra-g commented 26 December 2012 at 15:45

Priority:

Normal

» Major

Bumping priority to 'major'.

If we page at a sane # of items, we'll significantly reduce the # of calls to entity_access().

Comment #5

ezra-g commented 27 December 2012 at 20:36

Status:

Active

» Needs review

I committed the following changes:

- Views Litepager at 20 items/page with unique pager IDs, with the "Use ajax" option on the view
- Magic table headers unless we page the views
- Sort by flag created time rather than alpha.

Marking "needs review" to compare before/after.

http://drupalcode.org/project/commons_follow.git/commitdiff/1ff32a9?hp=2...