Agrupación de conexiones y la configuración del grupo de subprocesos en Java

hguser:

aplicación de la primavera usando la piscina Hikari.

Ahora para una sola petición del cliente tengo que consulta 10 mesas (de negocios es necesario), y luego el resultado compuesto juntos. Y consulta para cada mesa puede costar 50 ms a 200 ms. Para acelerar el tiempo de respuesta, creo una FixedThreadPoola mi servicio para consultar cada tabla de hilo diferente (pseudocódigo):

class MyService{
    final int THREAD_POOL_SIZE = 20;
    final int CONNECTION_POOL_SIZE = 10;


    final ExecutorService pool = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
    protected DataSource ds;


    MyClass(){
        Class.forName(getJdbcDriverName());
        HikariConfig config = new HikariConfig();
        config.setMaximumPoolSize(CONNECTION_POOL_SIZE);
        ds = new HikariDataSource(config);
    }



    public Items doQuery(){
        String[] tables=["a","b"......]; //10+ tables
        Items result=new Items();
        CompletionService<Items> executorService = new ExecutorCompletionService<Items>(pool);
        for (String tb : tables) {
            Callable<Item> c = () -> {
                Items items = ds.getConnection().query(tb); ......
                return Items;
            };
            executorService.submit(c);
        }


        for (String tb: tables) {
            final Future<Items> future = executorService.take();
            Items items = future.get();
            result.addAll(items);
        }
    }
}

Ahora para una sola solicitud, el tiempo medio de respuesta tal vez 500ms.

Pero para solicitudes simultáneas, el tiempo medio de respuesta se incrementará rápidamente, las más de las solicitudes, el largo tiempo de respuesta será.

Me pregunto cómo establecer el tamaño del grupo de conexión y agrupación de hebras de tamaño adecuado para hacer el trabajo de aplicación efectiva?

BTW, the database use RDS in cloud with 4 cpu 16GB mem, 2000 max connections and 8000 max IOPS.

skott :

You might want to think about a few more parameters:
1. Max concurrent request parameter for the database. Cloud providers have different limits of concurrent requests for different tiers, you might want to check yours.

2. When you say 50-200 ms, although it is difficult to say, are there 8 requests of 50ms and 2 requests of 200ms on an average or all of them pretty much the same? Why? Your doQuery might be limited by the query taking maximum time (which is 200ms), but the threads taking 50 ms will get released after it's task is done making them available for next set of requests.

3. What is the QPS you are expecting to receive?

Some calculations: If a single request takes 10 threads, and you have provisioned 100 connections with 100 concurrent query limit, assuming 200ms for each query, you can only handle 10 requests at a time. Maybe a little better than 10 if most queries take 50ms or so (but I wouldn't be optimistic).

Of course, some of these calculations goes for a toss if any of your queries takes >200ms (network latency or anything else) , in which case I recommend you have a circuit breaker, either at the connection end (if you are allowed to abort the query after a timeout) or at the API end.

Note : max connection limit is not the same as max concurrent query limit.

Sugerencia: Ya que se necesita respuesta de 500 ms bajo, Usted también puede tener una ConnectionTimeOut de alrededor 100-150ms en la piscina. Peor de los casos siguientes: ejecución de 150 ms de tiempo de espera de conexión + 200 ms + 100 ms consulta para el procesamiento de aplicaciones <500 ms por su respuesta. Trabajos.