Understanding asymmetric in jmh

Question

I'm reading about benchmarking with JMH and now considering the example of asymmetric.

They only said this:

So far all the tests were symmetric: the same code was executed in all the threads. At times, you need the asymmetric test.

At which exactly "times" I need such symmetric benchmarking. I don't understand any practical use case of that facility. They provide the following one:

private AtomicInteger counter;

@Setup
public void up() {
    counter = new AtomicInteger();
}

@Benchmark
@Group("g")
@GroupThreads(3)
public int inc() {
    return counter.incrementAndGet();
}

@Benchmark
@Group("g")
@GroupThreads(1)
public int get() {
    return counter.get();
}

But can you give me some real world use-case of that? I mean, what sort of things may I want to measure asymmetrically?

You need it when the test is only meaningful when some other action is being performed as in real life, you won't be doing just one action repeatedly. e.g. adding to a queue will get slower as it fills up, but in reality the queue might be typically empty. — Peter Lawrey, Oct 26 '16 at 12:38
@PeterLawrey I don't quite understand your example with queues. So in fact we want multiple thread to measure context-switch impact on performnce, is that what you meant? But as to Java's queues, they are non-blocking... so what do we want to achieve by such a benchmark? — St.Antario, Oct 27 '16 at 10:38
@St.Antario assuming the threads don't context switch you will still see jitter in the 1 to 100 mivrosecond range. With context switches you can see 1 to 100 ms jitter and this has an impact. This is even with non blocking strategies. — Peter Lawrey, Oct 27 '16 at 11:50

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

Programmatic encryption is a specific use case:

Symmetric keys simply means that the key that encrypt the data is the same key that will be decypting the data. Asymmetric keys means that the algorthm uses a different key to encrypt and decyprt the data.

In cases where performance is a valid concern, you can help minimize the performance hit from WS-Security by intelligent use of your security options. Certain web services frameworks tend to generate "all of the above" security configurations, with messages fully signed and encrypted using WS-Security and sent over SSL connections. That's fine if you really want maximum protection and don't care about performance, but in most cases it makes more sense to use either SSL (if you're only concerned about protecting the information in transit between the client and a single server) or WS-Security encryption (if you need to ship data across multiple servers while preserving confidentiality when going through the intermediaries).

You can also use WS-SecureConversation for long-running exchanges of messages between clients and a server (even one accessed through intermediaries), for a relatively modest but significant performance gain as compared to WS-Security using certificates. WS-SecureConversation works especially well in exchanges of relatively small messages where the added overhead of certificates and asymmetric encryption can be large in comparison to the actual (symmetric) encryption of the message body.

Concurrency bug test automation is another use case:

Several different approaches have been proposed recently to automatically fix concurrency bugs. These address concurrency problems resulting from inadequate synchronization, including atomicity violations, deadlocks, and data races. Roughly speaking, in all of these cases the fix amounts to inserting additional synchronization to inhibit bad interleaving scenarios.

And multi-core optimization:

In order to optimise performance, the JVM uses a "pseudo memory barrier" in code to act as a fencing instruction when synchronizing across multiple processors. It is possible to revert back to a "true" memory barrier instruction, but this can have a noticeable (and bad) effect upon performance.

References

Understanding asymmetric in jmh

1 Answers1