Bug #5556

[Workbench] Timeout error on collection#show for a collection with large manifest text

Added by Radhika Chippada over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
Workbench
Target version:
Start date:
03/25/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-

Description

Viewing this collection results in api server timeout error. In the last one week, I saw timeout errors at least 75% of the times when I tried to view this collection.

https://workbench.qr1hi.arvadosapi.com/collections/qr1hi-4zz18-tcnxylwkxg0nfhi

CollectionShowTimeout.png (535 KB) CollectionShowTimeout.png Radhika Chippada, 03/24/2015 03:33 PM

Subtasks

Task #5561: Review branch: 5556-collection-show-timeoutResolvedRadhika Chippada


Related issues

Related to Arvados - Bug #5560: [DRAFT] [API] Good API for accessing the old_ and new_attributes in Logs table properties columnNew

Associated revisions

Revision 46b124cc
Added by Radhika Chippada over 5 years ago

closes #5556
Merge branch '5556-collection-show-timeout'

History

#1 Updated by Radhika Chippada over 5 years ago

#2 Updated by Tom Clegg over 5 years ago

  • Category set to Workbench

Workbench with profiling enabled shows the logs#index API call taking longer than anything else, too.

I'm guessing the logs#index response contains multiple changesets, each with a "properties" hash containing a many-megabyte "old attributes" hash and a many-megabyte "new attributes" hash. Perhaps this (from CollectionsController#show) should use select() to avoid needlessly preparing/transferring/parsing those giant properties hashes:

        @logs = Log.limit(RELATION_LIMIT).order("created_at DESC")
          .where(object_uuid: @object.uuid).results

(Not sure, but it looks like Workbench doesn't do anything with the properties hash...)

#3 Updated by Radhika Chippada over 5 years ago

  • Status changed from New to In Progress
  • Assigned To set to Radhika Chippada
  • Target version changed from Bug Triage to 2015-04-01 sprint

#4 Updated by Brett Smith over 5 years ago

Reviewing 655469d

The new test confirms that toggling the new configuration setting doesn't break the API client. However, it does not confirm that the setting has any effect on the API client. If the API client ignored the setting completely, I believe both tests would still pass. Tom recently added test/unit/arvados_api_test.rb which has some basic mock support to test ArvadosApiClient directly. Would it maybe be possible to use this infrastructure to confirm that request headers do or don't include Accept-Encoding, as appropriate?

Thanks.

#5 Updated by Radhika Chippada over 5 years ago

Brett wrote:

The new test confirms that toggling the new configuration setting doesn't break the API client. However, it does not confirm that the setting has any effect on the API client. If the API client ignored the setting completely, I believe both tests would still pass. Tom recently added test/unit/arvados_api_test.rb which has some basic mock support to test ArvadosApiClient directly. Would it maybe be possible to use this infrastructure to confirm that request headers do or don't include Accept-Encoding, as appropriate?

I spent some time to see if I can see the request headers sent to server. I am not able to see this header. I did check by looking at the api server test log that the header is included. Since I did not find any easier (or other) way to see the header, I am going to move on. As you said, my goal was to verify that the code update did not have any negative side effects, which it serves. Thanks.

#6 Updated by Radhika Chippada over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:46b124cc766e4e35e40c1c3e2c1b388816aa682a.

Also available in: Atom PDF