[grepjava]

Case 3 of the perf-tools chapter first runs a command without --clientID to show it failing. That listing breaks --show-latency across two lines (--s / how-latency), and the error it quotes comes from the JMS session, while PerfClientCommand refuses the command before connecting.

This joins the option and quotes what the command prints, The clientID must be set on durable subscriptions, as seen on 2.57.0 with the rejoined command. The rest of the walkthrough is unchanged.

https://issues.apache.org/jira/browse/ARTEMIS-6349

[clebertsuconic]

As you have been doing a lot of tests in perf. Perhaps you could look into my PR on relational database (new storage )

Also. An idea. Use the table output on the perf tests.

[grepjava]

Thanks! Happy to run perf tests against #6838 once it's at a good point. I can test with PostgreSQL. Is there a particular scenario or comparison you'd like, and is the branch ready for that now? I'll open a separate issue for the table output too. Did you mean the final summary, the live lines, or both?

[clebertsuconic]

@grepjava for the table output.. I just meant to overal improve outputs in a more readable way. I know there's the final output.. but we could use it for anything else.

As for the current status... It's currently good to run tests.. I would do with postgresql.

(regarding the state for the relational database PR, I may break thinks eventually.. but I'm trying to keep it runnable... If I break it I tend to fix it quickly).

One test I run all the test is to send messages in transactions.. and consume them... at this point It's pretty much comparable with the journal for everything.

[grepjava]

@clebertsuconic the table output is up in #6871: the live statistics are now one table with a row per second, and the summary is two tables, with a sample in the PR. The row-per-second layout is my reading of "more readable", so tell me if you'd like it different.

The --show-latency output is a pair of tables per interval, as it doesn't fit in a row.

The PostgreSQL results for #6838 are in this comment. In short, it reached about 30-50% of the journal with the defaults, and lowering database-flush-period-nanos closed much of the gap.

The two perf tool problems I hit on the way are in #6867 (a producer's last transaction on close) and #6870 (consumer --tx never committed).