BK metrics

2018-03-20 Thread Vijay Srinivasaraghavan 
 Hello,

I am running a load test scenario where we have 3 Bookies, dedicated SSD's for 
journal and ledger, JVM heap size 5G with G1GC enabled. 

`jvm_opts: -Xmx5g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 
-XX:+ParallelRefProcEnabled -XX:+UnlockExperimentalVMOptions 
-XX:+AggressiveOpts -XX:+DoEscapeAnalysis -XX:ParallelGCThreads=32 
-XX:ConcGCThreads=32 -XX:G1NewSizePercent=50 -XX:+DisableExplicitGC 
-XX:-ResizePLAB -XX:+PrintFlagsFinal -XX:+PrintGC -XX:+PrintGCCause 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps`

 I am testing 1000 bytes record size, ingesting around 50M record at the 
ingestion rate limit 100K/sec.

I wanted to understand how the metric types `stats` are reported.
bookkeeper_server_ADD_ENTRY_REQUEST
bookkeeper_server_ADD_ENTRYJOURNAL_ADD_ENTRYJOURNAL_SYNCJOURNAL_QUEUE_LATENCYJOURNAL_FLUSH_LATENCYJOURNAL_PROCESS_TIME_LATENCY
My understanding is that the above metrics are reported in micro seconds (from 
BK code) and the reporters (we use statsD to collect BK metrics `codahale` and 
sink it to `InfluxDB`) converts the `rates` to seconds and `duration` to 
`milliseconds`

1) I wanted to confirm if the final graph values that I am seeing in the UI 
(attached) is represented in milliseconds or some other units?
2) If it's in milliseconds, are these numbers in expected range (see attached 
image). To me 2.5 seconds  (2.5K ms) latency for add entry request is very high.
Any help to understand the metrics is much appreciated.
RegardsVijay

Re: BK metrics

2018-03-20 Thread Ivan Kelly 
> 2) If it's in milliseconds, are these numbers in expected range (see
> attached image). To me 2.5 seconds  (2.5K ms) latency for add entry request
> is very high.
2.5 seconds is very high, but your write rate is also high. 100,000 *
1KB is 100MB/s. SSD should be able to take it from the journal side,
but it depends on the hardware.

Have you tried reducing the write rate to see how the latency changes?
What is the client seeing for latency? I assume the client and all
servers have  10GigE nics?

Your images didn't attach correctly. Maybe they're too big to post
directly to the list. There is a size limit, but I don't know what it
is.

-Ivan

Re: [DISCUSS] Inconsistency in Handle based APIs - Specifically "close"

2018-03-20 Thread Enrico Olivelli 
+1 on 3 forse me too

Il mar 20 mar 2018, 09:15 Sijie Guo  ha scritto:

> On Tue, Mar 20, 2018 at 12:50 AM, Ivan Kelly  wrote:
>
> > On Mon, Mar 19, 2018 at 6:37 PM, Sijie Guo  wrote:
> > > It is not a blocker for me.
> > >
> > > But if we want consistency, either applying pattern "asyncXYZ()" or
> > > "xyzAsync()" for async operations works for me.
> > xyzAsync is better than asyncXyz, as it will put the async and sync
> > versions together in the javadoc.
> >
> > So, there's 3 options here.
> >
> > 1. Remove Closeable
> > 2. Some kind of split of sealing and close
> > 3. Create sync and async versions of all with Async suffix.
> >
> > I think 3 is the most palatable. If there's no objections I'll push a
> > patch later today.
> >
>
> +1 on 3
>
> >
> > -Ivan
> >
>
-- 


-- Enrico Olivelli

Re: [DISCUSS] Inconsistency in Handle based APIs - Specifically "close"

2018-03-20 Thread Sijie Guo 
On Tue, Mar 20, 2018 at 12:50 AM, Ivan Kelly  wrote:

> On Mon, Mar 19, 2018 at 6:37 PM, Sijie Guo  wrote:
> > It is not a blocker for me.
> >
> > But if we want consistency, either applying pattern "asyncXYZ()" or
> > "xyzAsync()" for async operations works for me.
> xyzAsync is better than asyncXyz, as it will put the async and sync
> versions together in the javadoc.
>
> So, there's 3 options here.
>
> 1. Remove Closeable
> 2. Some kind of split of sealing and close
> 3. Create sync and async versions of all with Async suffix.
>
> I think 3 is the most palatable. If there's no objections I'll push a
> patch later today.
>

+1 on 3

>
> -Ivan
>

Re: [DISCUSS] Inconsistency in Handle based APIs - Specifically "close"

2018-03-20 Thread Ivan Kelly 
On Mon, Mar 19, 2018 at 6:37 PM, Sijie Guo  wrote:
> It is not a blocker for me.
>
> But if we want consistency, either applying pattern "asyncXYZ()" or
> "xyzAsync()" for async operations works for me.
xyzAsync is better than asyncXyz, as it will put the async and sync
versions together in the javadoc.

So, there's 3 options here.

1. Remove Closeable
2. Some kind of split of sealing and close
3. Create sync and async versions of all with Async suffix.

I think 3 is the most palatable. If there's no objections I'll push a
patch later today.

-Ivan