Project

General

Profile

Actions
Copy link

Bug #5023

closed

Readers pre-load is extremely slow with large numbers of users

Added by Boone Gorges almost 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Boone Gorges
Category name:
Social Paper
Target version:
1.9.2
Start date:
2015-12-11
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

In 1.9.1 I added some caching for the database queries, which helps. But the process of fetching usernames, printing them to a JS variable, and then letting Select2 build the markup - it's taking forever. I'm going to look into ways to make this process faster, before deciding whether to ditch the pre-load altogether.

(Note: this really only affects people who are members of many groups.)

Actions
Copy link
 #1

Updated by Boone Gorges almost 10 years ago

  • Status changed from New to Resolved

I decided to mitigate the problem by offloading the Readers pre-fill to an asynchronous request: https://github.com/cuny-academic-commons/social-paper/commit/61d3295ad18ad55f6dc1f9035d98a26b962b906b

For users with relatively few potential readers, this AJAX request should be pretty quick. For people like Matt, the request may still take a while, but at least now it won't block the pageload. Since the Readers interface is hidden in Edit mode, in the Settings panel, it's likely that in 99% of cases the request will be done by the time the user even sees it.

Let's see how this works on the production site after 1.9.2.

Actions
Copy link
 #2

Updated by Matt Gold almost 10 years ago

Thanks, Boone -- this sounds like a great change.

Actions
Copy link

Also available in: Atom PDF