[Archivesspace_Users_Group] Problems working with archival object with large number of direct children

[Jason Loeffler]

I should add that application performance was a hot topic in August last
year. Some of the issues described have been mitigated and/or implemented;
others not so much.

http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002285.html
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002319.html
http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2015-August/002346.html

On Tue, Nov 15, 2016 at 3:25 PM, Jason Loeffler <j at minorscience.com> wrote:

> Hi Sally,
>
> Definitely, yes. We have many resources with 5,000 or more archival object
> records. We've deployed on some pretty decent Amazon EC2 boxes (16GB
> memory, burstable CPU, etc.) with negligible improvement. I have a feeling
> that this is not a resource allocation issue. Looking at the web inspector,
> most of the time is spent negotiating jstree <http://jstree.com/> and/or
> loading* all JSON objects* associated with a resource into the browser.
> Maybe an ASpace dev can weigh in.
>
> From the sysadmin side, Maureen Callahan at Yale commissioned Percona to
> evaluate ArchivesSpace and MySQL performance. I've attached the report. Let
> me know if you need any help interpreting the report.
>
> At some point, and quite apart from this thread, I hope we can
> collectively revisit the staff interface architecture and recommend
> improvements.
>
> JL
>
> On Tue, Nov 15, 2016 at 2:37 PM, Sally Vermaaten <sally.vermaaten at nyu.edu>
> wrote:
>
>> Hi everyone,
>>
>> We're running into an issue with a large resource record in ArchivesSpace
>> and wonder if anyone has experienced a similar issue. In one resource
>> record, we have a series/archival object with around 19,000 direct
>> children/archival objects. We've found that:
>>
>>    - it takes several minutes to open the series in the 'tree'
>>    navigation view and then, once opened scrolling through series is very slow
>>    / laggy
>>    - it takes a couple of minutes to open any archival object in the
>>    series in edit mode and
>>    - it takes a couple of minutes to save changes to any archival object
>>    within the series
>>
>> Does anyone else have a similarly large archival object in a resource
>> record? If so, have you observed the same long load/save time when editing
>> the component records?
>>
>> The slow load time does not seem to be affected by memory allocation;
>> we've tried increasing the speed / size of the server and it seemed to have
>> no effect. We'd definitely appreciate any other suggestions for how we
>> might fix or work around the problem.
>>
>> We also wonder if this performance issue is essentially caused by the
>> queries being run to generate the UI view - i.e. perhaps in generating the
>> resource 'tree' view, all data for the whole series (all 19k archival
>> objects) is being retrieved and stored in memory? If so, we wondered if it
>> would be possible and would make sense to change the queries running during
>> tree generation, etc. to only retrieve some batches at a time, lazy loading
>> style?
>>
>> Thanks,
>> Weatherly and Sally
>>
>> --
>> Sally Vermaaten
>> Project Manager, Archival Systems
>> New York University Libraries
>> 1-212-992-6259
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161115/e441cee3/attachment.html>