[ https://issues.apache.org/jira/browse/PROTON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated PROTON-220: ------------------------------- Assignee: michael goulish (was: Alan Conway) > Create a set of "glass box" tests to quantify the performance of the proton > codebase. > ------------------------------------------------------------------------------------- > > Key: PROTON-220 > URL: https://issues.apache.org/jira/browse/PROTON-220 > Project: Qpid Proton > Issue Type: Test > Components: proton-c, proton-j > Reporter: Ken Giusti > Assignee: michael goulish > Labels: perfomance, test > > The goal of these tests would be to detect any performance degradation > inadvertently introduced during development. These tests would not be > intended to provide any metrics regarding the "real world" behavior of > proton-based applications. Rather, these tests are targeted for use by the > proton developers to help gauge the effect their code changes may have on > performance. > These tests should require no special configuration or setup in order to run. > It should be easy to run these test as part of the development process. The > intent would be to have developer run the tests prior to making any code > changes, and record the metrics for comparison against the results obtained > after making changes to the code base. > As described by Rafi: > "I think it would be good to include some performance metrics that isolate > the various components of proton. For example having a metric that simply > repeatedly encodes/decodes a message would be quite useful in isolating the > message implementation. Setting up two engines in memory and using them to > blast zero sized messages back and forth as fast as possible would tell us > how much protocol overhead the engine is adding. Using the codec directly > to encode/decode data would also be a useful measure. Each of these would > probably want to have multiple profiles, different message content, > different acknowledgement/flow control patterns, and different kinds of > data. > I think breaking out the different dimensions of the implementation as > above would provide a very useful tool to run before/after any performance > sensitive changes to detect and isolate regressions, or to test potential > improvements." -- This message was sent by Atlassian JIRA (v6.3.4#6332)