Thank you for contributing to the discussion Stephen!
I'll defer to Jason and Mike's expertise on how database communications are handled, but in terms of improving queries to optimize performance, I do see this as something that a performance analysis should address. Following up on Mike's request for details, I think what would be helpful is to hear where those queries can be improved.
For many of us, we might not know that a performance problem is caused by a query that could be optimized; we just know that a particular interface loads slowly or that a particular function takes too long complete. All of that information is highly useful, even if you don't know what the underlying cause of the problem is. We can leave it up to the Mikes and the Jasons and the performance analysts of the world to figure it out for us. I know I've already mis-categorized one of the problems I identified, but that's okay because the important point is that we make sure those problems are indeed identified.
The bigger point implied in the initial email, and what I wanted to address more broadly, is that QA is seen as "someone else's problem" and it's that someone else's (presumably the RM's) responsibility to test, identify and repair defects. I disagree with that. I think we can all play a part -- even if we don't know we are doing so -- and should. There's plenty in both scale and breadth to do.
I tend to agree with Mike's statement. Being part of an open-source project, I think we all take responsibility for the quality of the product and the resources that support that product (i.e. documentation, communication, etc.). You don't need to be a developer or systems person to make a contribution to the software or the community that supports it.
For those who don't know me, I am not a systems person, I know very little about code, and, up until a few weeks ago, I never gave much thought to what might go into a software performance analysis. I'm hoping this discussion thread and the corresponding wiki page at http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:testing:performance_issues is seen as an open invitation for other non-developer folks like me to identify where those pain points are in the software and to make a contribution to the solution. You might not think you are making a big contribution, but any further data on places where performance could be optimized is very helpful. Those who are using the system on a daily basis or supporting those who use it on a daily basis are the most qualified to identify those times when the software makes them wait too long for a response.
Of course, I want to hear from all those technical folks as well, because you all could provide insight on some of the backend functions that the average user may not see. The more people we hear from in this discussion, no matter what the skill level, the better position we will be in to start any type for performance analysis.
Kathy
