10 minutes is definitely too slow if it happens after the initial building of the map of all shards and their locations. One thing that would help evaluate some of the latency issues is to run the following query and see how long it takes:

SELECT LOWER(t.table_schema), LOWER(t.table_name) FROM information_schema.tables t 

UNION ALL 

SELECT LOWER(s.schema_name), '' FROM information_schema.schemata s;

This is the query that the schemarouter executes to determine which tables are visible for which users.

One thing I did notice is that if you have log_info=true, the performance will be much slower as the majority of the time is spent writing debug log data into the log files. Checking whether it's on via maxctrl show maxscale would be a good sanity check to make.

The given test case is pretty much the worst-case performance you can get from schemarouter: the shard map cache won't be of any use as all users are unique and each of them builds the shard map when it starts. The default cache validity of 300 seconds isn't helping here that much either so increasing that to something like refresh_interval=24h would also be sensible (assuming the set of tables and databases insn't constantly changing).

I did find some odd slowness in the schemarouter even in the case where the shard map is found in the cache: compared to a readwritesplit service which took 4 seconds, the schemarouter took around 7 seconds to iterate over 1000 users and do a SELECT 1. This was with the command line client so one of the queries it does might cause this slowness; further testing is requried.

Closing as Not a Bug since this is very much expected behavior with the way the schemarouter was designed to work.

Sequentially executing SQL statements by using a separate user for each statement is expected to take longer as it forces the schemarouter to build the shard location map every time the user logs in. This effectively bypasses the whole caching that is in place for it and is comparable to using InnoDB with no buffer pool.