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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group >> >> >
_______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
