Kathy, Are do you want some information like workflows that seem slow? For instance, just got a report from a library about specific steps they are doing to catalogiing where certain individual processes are slow.
Tim On Wed, Feb 27, 2013 at 11:37 AM, Kathy Lussier <[email protected]>wrote: > Hi all, > > It was brought to my attention that everyone who may have some input for > this discussion may not have an Evergreen wiki account. In that case, > please feel free to send an e-mail (to the list, not directly to me) > identifying any performance issues you believe should be addressed through > a performance evaluation. I'll be happy to add them to the wiki. > > What I'm looking for is: > > 1. Any specific paint points you see in performance. > 2. Any specific questions you think a performance evaluation should answer. > 3. Any ideas you might already have regarding causes of performance > problems. In reading through the logs from the "future of the staff client" > meeting, I noticed several people said they thought it was important to > bring these ideas together before reaching out to a consultant, and I agree > that this is an important first step in the process. > > I posted just a few of our local issues at > http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:testing:performance_issues > : > > STAFF CLIENT: > > Memory leaks - is there an inherent problem with the technology used in > the staff client (xulrunner, Dojo) that is the source of the memory leak > problem and other performance problems? > Slow retrieval of patron records > > MESSAGING (OPENSRF): > Staff client batch operations (e.g. updates/deletes from copy buckets) > > DATABASE: > Catalog search - is there a way to optimize searching in the catalog so > that users get faster results and are able to start re-implementing things > like search.relevance_adjustment to provide boosts to relevance ranking? > > I'm quite sure there are far more pain points out there, so please don't > feel shy about contributing to the list! > > > Kathy > > > > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative(508) [email protected] > Twitter: http://www.twitter.com/kmlussier > > On 2/25/2013 11:44 AM, Kathy Lussier wrote: > > Hi all, > > Having heard no objections to proceeding with finding somebody to do a > software performance analysis, I have created a page on the wiki at > http://www.open-ils.org/dokuwiki/doku.php?id=dev:testing:performance_issueswhere > we can identify the pain points that need further evaluation and add > any questions that we hope a performance analysis might be able to answer. > > I have started the list off with some basic issues/questions that have > come up in our own systems. During the future of the staff client meeting, > Dan Scott had mentioned that there might be three points of attack:client, > opensrf, database. I thought dividing the list into those three areas > might be a good way to start. > > I'm hoping that all the knowledgeable sys admins out there who have a > stronger understanding of the system architecture than I do can build this > list into something that might be a good starting point for any performance > evaluation, whether it's done by a third party or by somebody in the > Evergreen community. By identifying the questions we hope a performance > evaluation might answer, we are also identifying what our expectations are > before we enter the process. I would want to be clear on our expectations > before formally talking to any third party so that we can be fully informed > about whether an evaluation could meet those expectations. > > Kathy > > > Kathy Lussier > Project Coordinator > Massachusetts Library Network Cooperative(508) [email protected] > Twitter: http://www.twitter.com/kmlussier > > On 2/20/2013 2:26 PM, Mike Rylander wrote: > > On Wed, Feb 20, 2013 at 2:10 PM, Kathy Lussier <[email protected]>wrote: > >> Hi all, >> >> I wasn't sure if I should add this to the QA discussion, but it seemed >> worthy of its own thread. >> >> During the "future of the staff client" meeting, I advocated for bringing >> in a consultant to do a software performance analysis for Evergreen to help >> us identify where the critical bottlenecks are in the system in the hopes >> that we could then identify the areas that need to be worked on to improve >> performance. At the time, I didn't have any concrete suggestions on finding >> a consultant who could take on this project, but I have since done some >> more investigation and have a couple of leads, the most promising of which >> is an individual local to Massachusetts who previously worked for many >> years at Stratus Technologies where he was involved in all levels of >> performance analysis. He now teaches graduate-level courses on performance >> evaluation and also does contract work. >> >> Now that I actually have concrete leads, I would like to get the ball >> rolling, provided there is support from the larger community. I'm not quite >> sure how this might fit in with ESI's planned QA efforts or with the >> possibility of bringing in a firm like OmniTI as Dan suggested, but my >> reading into these QA e-mails is that the focus would be on testing new >> commits. >> > > I want to clarify something that Dan seems to have assumed incorrectly: > that anything ESI does is mutually exclusive with bringing in outside > expertise. Nobody has any grounds to stop such an effort, and it would > be ridiculous to argue otherwise, words put into my mouth notwithstanding. > The initial focus of an ESI effort will be what exists today, through > infrastructure, so that what exists tomorrow can then be tested. > > As for how it would fit in, ESI would absorb and internalize any advice > or direction, just like any other community member, and work within the > community to incorporate that. > > So, why have ESI involved at all? Besides the fact that we create a > significant portion of the code, and that it benefits us as much as anyone > to have a more stable Evergreen, there is a need for ongoing, active > leadership in QA. The fact is that it has not materialized yet, so we're > looking for a way to make that a maintainable proposition for the > community's benefit. That means ongoing, deep integration with both > developer and user communities. And that is not something that we can > expect from OmniTI or any other organization that is not plugged into those > communities. Could some other organization step into that role, and > provide years of ongoing QA support? Perhaps so, but ESI exists today and > has the Evergreen expertise needed to avoid long (and costly) ramp-up time. > > The point is this, though, ESI will encourage any effort to improve > Evergreen, and is willing and able to work in the community, as we always > do, to further those efforts. > > Thanks, Kathy! > > -- > Mike Rylander > | Director of Research and Development > | Equinox Software, Inc. / Your Library's Guide to Open Source > | phone: 1-877-OPEN-ILS (673-6457) > | email: [email protected] > | web: http://www.esilibrary.com > > > > -- Tim Spindler [email protected] *P** Go Green - **Save a tree! Please don't print this e-mail unless it's really necessary.*
