Atualmente, tenho um aplicativo implantado usando o Tomcat que interage com um banco de dados Postgres via JDBC. As consultas são muito caras, então o que estou vendo é um tempo limite causado pelo Tomcat ou Apache (o Apache fica na frente do Tomcat na minha configuração). Estou tentando limitar as conexões ao banco de dados para 20 a 30 conexões simultâneas, para que o banco de dados não fique sobrecarregado. Eu fiz isso usando a configuração \ .., definindo maxActive como 30 e maxIdle como 20. Eu também aprimorei o maxWait.

Neste cenário, estou limitando o USO do banco de dados, mas quero que as conexões / solicitações sejam POOLED no Tomcat. O Apache pode aceitar 250 solicitações simultâneas. Portanto, preciso garantir que o Tomcat também aceite tantos, mas lide com eles de maneira apropriad

Tomcat possui duas configurações HTTP Connector arquivo de configuração:

maxThreads - "Número máximo de threads de processamento de solicitações a serem criados pelo Conector Http, que, portanto, determina o número máximo de solicitações simultâneas que podem ser tratadas." acceptCount - "O tamanho máximo da fila para solicitações de conexão recebidas quando todos os encadeamentos possíveis de processamento de solicitações estiverem em uso. Quaisquer solicitações recebidas quando a fila estiver cheia serão recusadas."

Então, suponho que se eu definir maxThreads para o número máximo de conexões JDBC (30), então eu posso definir acceptCount como 250-30 = 220.

Eu não entendo bem a diferença entre um thread que está ESPERANDO em uma conexão JDBC para abrir do pool, versus um thread que está na fila ... Meu pensamento é que um thread na fila está consumindo menos ciclos, enquanto um thread em execução , aguardando no pool JDBC, passará ciclos verificando o pool em busca de um encadeamento gratuito ...?