[ 
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)

Reply via email to