793581 - Creating a test suite in moztrap lately has been moving at a crawl (long load times)

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: MozTrap, defect)

Description

[Jason Smith [:jsmith]]

Lately on the production server (moztrap.mozilla.org), the overall time it takes to create a test suite moves at an absolute crawl. The processes that move slow include:

- Selecting the option to create a test suite
- Selecting a product
- Filtering a set of test cases

Could be a scalability problem, but its really slowing down test suite creation.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Video with Web Console open to show slowness.

http://www.youtube.com/watch?v=JdY-_o9EIuo&feature=youtube_gdata_player

Comment 2

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/36803249

Comment 3

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I believe this has to do with the multi-select widget not chunking the data it retrieves.  As the number of test cases increases into the hundreds, this is falling down.

Comment 4

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
pt doesn't allow estimates on bugs.  but I estimate this as 2 to 3 days work to fix.

Comment 5

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I've had several conversations with a few people about approaches to this.  There are several parts to a fix to this.

1. upgrade to django 1.4.  The newer version has a feature which can dramatically improve the performance of the query for the test case data.  

2. delay fetching of the test cases until we know which product we are going to fetch for.

3. optimize how much data we fetch.  if we need less fields, that would be a quicker query

4. some kind of chunking.  this is a harder problem to solve.  I'm hoping to delay doing this to a later time.  But that will depend on how much perf gain we get out of the rest of this.

Comment 6

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
I spoke to jonny on irc today.  here are a bunch of his comments and suggestions:

- your JS function should add an event handler to listen for every time that product option changes (see line 90 of manage-products.js): find the URL for whatever product was chosen (from the data-attribute or wherever you stored it), and make an ajax GET call to that URL to get a JSON object.
- you'll want to pass that JSON object through an ICanHaz template in jstemplates/ (look at the ones already there for help, or see http://mustache.github.com/mustache.5.html ). Then you basically just insert the returned HTML into the DOM (see line 76 of manage-products.js)
- note that for ICanHaz to recognize your new template, you need to initialize it somewhere in the html templates (see, e.g. _filtered_select_multiple.html)
-

Comment 7

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
More from Jonny:


so basically, every place where you want to use this new ajax model, you need to find the django template where the cases are being loaded into the multiselect widget
you'll want to remove the cases from the django template, and turn them into a new icanhaz template instead
after looking at it, i think we're really only talking about one template
templates/forms/widgets/filtered_select_multiple/_filtered_select_multiple_item.html
that's the template that's being used to render each case
we want to copy that template to make a new icanhaz template in jstemplates/
and we also want to remove it from the django template on the pages where we're ajaxifying things, so the widget doesn't start pre-loaded with cases anymore
also, it looks like the _filtered_select_mutliple_item template is actually extended by two other templates, so you'll have to find ways to copy those into the jstemplate as well: templates/manage/run/suite_select/_suite_select_item.html and templates/manage/suite/case_select/_case_select_item.html.
(if you want to convert those pages)
broad picture, this is the goal: make it so that the widget loads empty (by making changes in the django template), and then make a jstemplate that can receive the JSON object and turn it into whatever markup we removed from the widget

Comment 8

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to started in Pivotal Tracker

Comment 9

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
New estimate is more like 2 weeks.  There was a steep learning curve for the code base in this area.

Comment 10

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to finished in Pivotal Tracker

Comment 11

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker

Comment 12

[Cameron Dawson [:camd]]

Cameron Dawson changed story state to accepted in Pivotal Tracker

Comment 13

[Peter Bengtsson [:peterbe]]

I'm pretty sure this was fixed with these two commits:

# made the drop-down client side much faster
https://github.com/mozilla/moztrap/commit/cf173714a98de18c5cb61b265919beed28d12755

# made the server-side results more than 10 times faster on big results
https://github.com/mozilla/moztrap/commit/3072f3127034651cf1f567d71beae50838f98be4

It's still sluggish but that's because Firefox OS has so incredibly many test cases to chose from.