I am not sure I understand why higher innodb_concurrency tickets will reduce throughput ? For me it looks opposite – the higher value will allow less “interruptions” while running queries and less overhead while checking concurrency. It will however increase variance – the larger is the value there is a longer period the query can starve for.

The trick is as thread is considered “inside innodb” when it is doing IO as well as when it is processing data in memory, so the time to which given number of tickets correspond can vary.
500 tickets may amount to less than ms if small rows are accessed in memory or more than as second if accessing all rows requires physical disk IO

—TRANSACTION 0 58505, COMMITTED IN MEMORY, process no 1366, OS thread id 68725056 committing, thread declared inside InnoDB 17

That 17 is number of trx->n_tickets_to_enter_innodb

[...] will be a technical talk, but perhaps less technical than some of our other posts. I recommend inviting a few friends & colleagues that are already familiar with MySQL, but [...]

how to check that > maximum number of concurrent threads that the InnoDB plug-in can create