The new direct subscription overlay takes too long to load

[Graham Binns]

What happens:
As a member of the malone-alpha team, go to a bug and click on the Subscribe link (or Edit subscription if you're already subscribed). The overlay will appear and then, a couple of seconds later, the form inside it will be populated. This takes time because we load the form from Bug:+subscribe/++form++, so there's an extra request and server time to deal with.

What should happen:
The overlay should be ready to go before it gets displayed. This means that it should be populated when the page is first loaded and should be repopulated after the user has edited their subscription. The loading of the Zope form shouldn't happen just after the user has clicked the Edit subscription / Subscribe link.

[Robert Collins (lifeless)]

The couple of second latency is due to in data centre queuing and
(possibly) a fat form render.

You should be able to get subsecond once we have the in data centre
queuing sorted, particularly if you make the form render itself lean
and mean.

I encourage you to wontfix this bug.

[Robert Collins (lifeless)]

> I encourage you to wontfix this bug.

... because you will make /every/ page load wear the cost of the form
generation even if its only needed for 1% of page loads.

[Gary Poster (gary)]

I agree with Robert's basic position (AIUI) that we should not pursue the proposed approach of pre-loading the form.

The heart of the feature we are working on right now is usability, so I want significant usability problems to be addressed. I'm not weighing in on whether this is a significant issue right now--it sounds like I might agree that it is, but I'll let Graham make that decision, with the input of others as he feels is appropriate.

Making the form rendering fast would be a great solution. Alternatively or in addition, making the widget show an "I'm working" status while it is loading (e.g., the ever-popular swirling circle) might be a way to approach this.

[Graham Binns (gmb)]

On 15 February 2011 15:25, Gary Poster <email address hidden> wrote:
> I agree with Robert's basic position (AIUI) that we should not pursue
> the proposed approach of pre-loading the form.

Rob and I discussed this on IRC earlier and the fact that setting up
the links to use the overlay is done asynchronously at the moment does
mitigate the cost somewhat. However...

> Making the form rendering fast would be a great solution.  Alternatively
> or in addition, making the widget show an "I'm working" status while it
> is loading (e.g., the ever-popular swirling circle) might be a way to
> approach this.

This is not a bad idea at all (since we already use the spinner when
you've just used the link to make a change to your subscription).

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12411 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12411>.

[Robert Collins (lifeless)]

See also bug 722450. Something got lost confused in the discussions around this; I've talked with Gary and we're both happy to roll the implementation that was done back. We can tolerate the overhead for a few days.

The right long term solution to this is something like:
 - wait for the datacentre load issues to be resolved - we're currently overloaded with a sustained backlog of 60 requests (4*15 instances)
 - optimise the form so that when its loaded it renders quickly - e.g. < 0.2seconds. - on the server

Then our worst case should be RTT + 0.2 seconds - or 0.5 seconds in .au, 0.3 in the US and 0.2 in europe.