hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Performances Tests
Date Sat, 09 Mar 2013 03:30:37 GMT
Tangentally: I think I prefer LoadTestTool over PerformanceEvaluation, it
doesn't depend on nor is influenced by MapReduce job startup.


On Fri, Mar 8, 2013 at 10:05 PM, ramkrishna vasudevan <
ramkrishna.s.vasudevan@gmail.com> wrote:

> @JM
> I agree with you.  Mainly the perf improvement changes needs some
> testcases.
> But sometimes the scenario on which the perf improvments happens are bit
> difficult to generate and we will be able to do in a standalone case only.
>  May be overall if we need to get that perf improvment result we need a
> real cluster with suitable data.  That is what i have experienced.  Just
> telling.
>
> Regards
> Ram
>
> On Fri, Mar 8, 2013 at 7:28 PM, Jean-Marc Spaggiari <
> jean-marc@spaggiari.org
> > wrote:
>
> > Hi,
> >
> > In HBase we already have PerformanceEvaluation which gives us a good
> > way to validate that nothing broke HBase speed in the recent updates.
> >
> > I can see in the JIRAs many improvements coming, like for the lazy
> > seeks, the bloom filters, etc. however, there is no tests for those
> > improvements.
> >
> > Will it not be good to ask people to add some new tests in
> > PerformanceEvaluation when they are introducing an improvement which
> > is not covered there?
> >
> > We should not touch existing tests because we need to have a way to
> > compare the baseline between the different versions, but we can still
> > add some new. Like in addition to RandomSeekScanTest we can add
> > RandomSeekScanBloomEnabledTest and so on. And even better if we can
> > back port those new tests to previous version.
> >
> > The same way we add a test class when we introduce a new feature,
> > should we add a performance test method to test it too?
> >
> > JM
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message