We've done no benchmarking or performance to date, since we've been focused on functionality. In part this is because we all know that Kafka can be configured to handle very large volumes of messages with quite small latencies, and this involves tuning not only the Kafka broker configurations but also the producers (and consumers). Since Kafka Connect is largely just an implementation that uses producers with well-known and highly-performant patterns (e.g., recording the offsets periodically, etc.), this also should be able to be tuned to perform quite well. And although we don't known how many high-volume connectors could be deployed/run in a single Kafka Connect service instance, in some respects that doesn't matter too much since we can always add more service instances to the cluster or even create additional Kafka Connect clusters.
Having said that, we do not know the performance or capabilities of the MySQL connector and the library it uses to read the binlog. We also don't know the impact that a single connector has on the server or that writing row changes to the binlog has on MySQL server performance, though the latter is (always?) a prerequisite for MySQL clustering.
Best regards,
Randall