Para evitar a sobrecarga de estabelecer uma nova conexão cada vez que uma consulta precisa ser disparada contra o MySQL, há duas opções disponíveis:

Conexões persistentes, nas quais uma nova conexão é solicitada, é feita uma verificação para verificar se uma conexão 'idêntica' já está aberta e, se for o caso, use- Pool de conexão, em que o cliente mantém um pool de conexões, para que cada thread que precise usar uma conexão faça check-out de um pool e retorne ao pool quando termina

ntão, se eu tenho um aplicativo de servidor multiencadeado para lidar com milhares de solicitações por segundo e cada thread precisa disparar uma consulta no banco de dados, qual é a melhor opçã

Do meu entendimento, com conexões persistentes, todos os threads no meu aplicativo tentarão usar a mesma conexão persistente com o banco de dados porque todos eles estão usando conexões idênticas. Portanto, é uma conexão compartilhada entre vários segmentos de aplicativos - como resultado, as solicitações serão bloqueadas no lado do banco de dados em brev

Se eu usar um mecanismo de pool de conexões, todos os threads de aplicativos compartilharão um pool de conexões. Portanto, há menos possibilidade de uma solicitação de bloqueio. No entanto, com o pool de conexões, um encadeamento de aplicativo deve esperar para adquirir uma conexão do pool ou enviar uma solicitação sobre as conexões no pool de qualquer maneira, de maneira round-robin, e permitir que o enfileiramento, se houver, ocorra no banco de dados?