accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wsla...@gmail.com>
Subject Re: measuring perf
Date Fri, 10 Jun 2016 14:53:55 GMT
I think it's reasonable to measure from the start of a for/while loop over
the Scanner. Such as:

```
// .. my initialization code
scanner.setRange(someRange)
Stopwatch timer = Stopwatch.createStarted();
for(Entry<Key, Value> e: scanner) {
  // my logic
}
timer.stop();
```
I've personally done this when measuring query performance and usually
gives a good estimate of what's going on, especially if the network has
low, constant latency.


On Fri, Jun 10, 2016 at 3:35 PM, z11373 <z11373@outlook.com> wrote:

> Good morning!
> I have a service running against different Accumulo instance (in different
> datacenter).
> Both Accumulo should have same configurations, but I was told by consumer
> of
> my service is they experience one is faster than one in another datacenter.
> The service being deployed is running on machine with same spec, and most
> operations are against Accumulo, hence I am interested to capture the perf
> (including network latency from Accumulo server to my service), and compare
> them to verify if the problem is indeed accessing Accumulo instance is
> slower than the other one. Right now I capture time from my service being
> called and results being returned, but that doesn't tell how much time it
> spent on Accumulo.
>
> Unlike in traditional SQL database, I could measure the time it takes to
> run
> a SELECT statement for example, but in Accumulo, nothing being read from
> server, until we iterate (my understanding may be wrong), so for now I am
> thinking perhaps I'd set the start time before setting the ranges, and set
> the stop time when there is no more item from that iterator. Is this
> reasonable, or perhaps there is a better way?
>
> For additional info, my service will read from iterator, for each item, it
> will make another scanner (and set range), and iterate again, and so on. So
> if it ends up with 10 scanners, my current approach will log 10 perf
> captures.
>
>
> Thanks,
> Z
>
>
>
> --
> View this message in context:
> http://apache-accumulo.1065345.n5.nabble.com/measuring-perf-tp17245.html
> Sent from the Developers mailing list archive at Nabble.com.
>

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