Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Bom eu estava pensando em ter dois usuarios uma para leitura e outro para crud, assim tdos select iria usar em uma conexão e o resto na outra sendo que a conexão voltada para os selects ficaria aberto o tempo todo.
perguntando sobre isso na aba de DB o pessoal pediu para eu pesquisar sobre Pool de conexões, mas só estou achando tutorial de outras linguagens, e até encontrei um de PDO todo ingles... mas estou vendo se consigo intender como funciona e se entendo o algoritimo. se alguem tiver uma base para eu poder seguir de modelo eu agradeço.
mas fica uma pergunta - Deixo padrao fexando a abrindo conexao a cada chamado ou
Uma conexao aberta para leitura e uma padrao que só abre para alterar dados, ou faço esse pool?
voce fala deixar só uma conexao aberta?
Bom, antes de tudo, explique melhor o seu problema. Dessa forma, ficará mais fácil lhe ajudar.
Não sou um expert em pool de conexão, e só conhecia o pool de impressão e sua origem para resolver um problema (condição de corrida). Então eu fui pesquisar.
Conforme estive pesquisando, você dependerá de configurações, tanto no SGBD como no PHP para utilizar de pool de conexão. Mais no SGBD, para falar a verdade.
Diferentemente de .NET, que possui pool de conexão, conforme eu li, o PHP não possui. Conforme poderá ler nessa Thread:
http://stackoverflow.com/questions/39753/connection-pooling-in-php
O PHP, possui ciclo de vida por execução. Você realiza a requisão, o servidor interpreta o PHP, realiza sua execução e devolve uma resposta. Após a resposta, tudo que foi utilizado, com pequenas exceções (sessions/cookies, pconnect e possivelmente mais), não existirá mais. O mesmo acontece com conexões com SGBD. Exceto a conexão pconnect, que sempre se mantem ativa. Entretanto, não é nenhum um pouco recomendável utilizar pconnect, pois o PHP, após a execução do script, elimina as conexões para liberar a banda do SGBD.
Apesar de pconnect, por alguns, serem considerados um Pool de conexão, ele não é. Entretanto, conforme poderá ver nos artigos abaixo da Oracle, se utilizado em conjunto com o SGBD, poderá sim, ser um pool de conexão.
https://blogs.oracle.com/opal/entry/highly_scalable_connection_poo
http://www.oracle.com/technetwork/topics/php/php-scalability-ha-twp-128842.pdf
A PDO realiza o encapsulamento da conexão, assim, durante a execução, você terá uma única conexão por instância da aplicação (se houver 2 usuários acessando o site/sistema, possuirá 2 conexões) e a utilizando durante toda a execução do script. O que é bastante recomendável.
Caso você deseje utilizar uma pconnect com PDO, você deve atribuir a constante ATTR_PERSISTENT. Seria o seguinte:
$conn = new PDO("mysql:host=localhost;dbname=basename", 'root' , 'password' , array(PDO::ATTR_PERSISTENT => true));Mas não vejo uma real necessidade de um pool de conexão. É mais recomendado você se preocupar com a engenharia empregada no uso das classes e das conexões (quantidades absurdas de consultas), para consumir menos o servidor, do que se preocupar em criar um pool de conexão. Já trabalhei com aplicações grandes em PHP e não houve problemas com consultas excessivas, mas o seu SGBD deve possuir indexes conforme a quantidade de registros, isso é extremamente necessário.
Então o que eu disse a respeito do PDO fazer pool de conexões estão corretas, Gabriel Heming? Aliás, já li na documentação sobre essas constantes. :thumbsup:
As informações estão quase corretas. A PDO, em conjunto com o SGBD, pode sim realizar o pool de conexão. Mas ela, por si só, não realiza. A PDO é um Façade, além de manter uma interface comum e simplificada, em relação aos SGBDs, ela realiza o encapsulamento da conexão. Mas somente isso, não é um pool.
Eu estive procurando uma definição concreta de pool. Mas todas que eu encontrei são um tanto confusas. Até onde eu entendo, pool, na computação, pode ser conceituado como uma estrutura do tipo fila, onde você adiciona processos e esses serão executados na ordem em que foram inseridos, exatamente como é uma fila de supermercado, quem entrou antes, será executado antes.
Apesar da programação "enfileirar" os scripts (exceto em treads), você envia uma requisição por vez ao SGBD. O SGBD processa em paralelo todas as requisições de cada conexão. No caso de você possuir 3 conexões e enviar 3 requisições, uma de cada vez, elas não serão respondidas em ordem de recebimento, como espera-se de um pool. A requisição que for executada mais rápido, terá a resposta primeiro, indiferente da ordem de envio.
Se você for testar com a impressora, envie um arquivo de 100 páginas e logo após, um arquivo de uma página. Como espera-se de um pool, você receberá primeiro a impressão de 100 páginas e logo após a impressão de uma página. Na PDO, sem as configurações necessárias entre PDO e SGBD, você recebera primeiro a que possuir a execução mais rápida.
+1 pra ti. Diante disso, tive boas idéias aqui que não tinha pensado! :thumbsup:
>
Não sou um expert em pool de conexão, e só conhecia o pool de impressão e sua origem para resolver um problema (condição de corrida). Então eu fui pesquisar.
Conforme estive pesquisando, você dependerá de configurações, tanto no SGBD como no PHP para utilizar de pool de conexão. Mais no SGBD, para falar a verdade.
Diferentemente de .NET, que possui pool de conexão, conforme eu li, o PHP não possui. Conforme poderá ler nessa Thread:
http://stackoverflow.com/questions/39753/connection-pooling-in-php
O PHP, possui ciclo de vida por execução. Você realiza a requisão, o servidor interpreta o PHP, realiza sua execução e devolve uma resposta. Após a resposta, tudo que foi utilizado, com pequenas exceções (sessions/cookies, pconnect e possivelmente mais), não existirá mais. O mesmo acontece com conexões com SGBD. Exceto a conexão pconnect, que sempre se mantem ativa. Entretanto, não é nenhum um pouco recomendável utilizar pconnect, pois o PHP, após a execução do script, elimina as conexões para liberar a banda do SGBD.
Apesar de pconnect, por alguns, serem considerados um Pool de conexão, ele não é. Entretanto, conforme poderá ver nos artigos abaixo da Oracle, se utilizado em conjunto com o SGBD, poderá sim, ser um pool de conexão.
https://blogs.oracle.com/opal/entry/highly_scalable_connection_poo
http://www.oracle.com/technetwork/topics/php/php-scalability-ha-twp-128842.pdf
A PDO realiza o encapsulamento da conexão, assim, durante a execução, você terá uma única conexão por instância da aplicação (se houver 2 usuários acessando o site/sistema, possuirá 2 conexões) e a utilizando durante toda a execução do script. O que é bastante recomendável.
Caso você deseje utilizar uma pconnect com PDO, você deve atribuir a constante ATTR_PERSISTENT. Seria o seguinte:
$conn = new PDO("mysql:host=localhost;dbname=basename", 'root' , 'password' , array(PDO::ATTR_PERSISTENT => true));Mas não vejo uma real necessidade de um pool de conexão. É mais recomendado você se preocupar com a engenharia empregada no uso das classes e das conexões (quantidades absurdas de consultas), para consumir menos o servidor, do que se preocupar em criar um pool de conexão. Já trabalhei com aplicações grandes em PHP e não houve problemas com consultas excessivas, mas o seu SGBD deve possuir indexes conforme a quantidade de registros, isso é extremamente necessário.
entao eu estou em um projeto, fiz uma classe de conexão q é a pai, e duas subclasse uma da da estrutura da query e otra de crud, uma extendendo a outra.
porem a cada Objeto ele faz uma nova conexão, e no final finaliza a mesma.. só que eu estava pensando isso nao iria pejudicar o desempenho do site?
Desculpe as perguntas mas é que o POO eu aprendi recentemente, antes eu deixar uma conexão para o site geral.. mas pelo q vi no POO a conexão é iniciada a cada objeto.
outra coisa é que ta me deixando P. é que meu local host ta muito lento aí eu fico na duvida se tem algo errado com o site.. mas creio q é compatibilidade do wamp mesmo.
esqueci de comentar nao entendo muito do pconect
minha classe de conexão esta assim:
<?php
class Conexao{
//DADOS DA CONEXÃO
protected $_conection;
protected $_conecta;
const _host = 'localhost'; //NOME DO SERVER
const _db = 'site'; //NOME DO USUÁRIO
const _user = 'root'; //NOME DO BANCO DE DADOS
const _pass = 'xxxx'; //SENHA/*--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------*/
//FUNÇÃO CONSTRUTORA
public function __construct(){
//INICIA A CONEXAO
$this->Start();}//FECHA FUNÇÃO CONSTRUTORA
/*--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------*/
//METODO DE CONEXAO PDO
protected function Start(){
//CONEXÃO
$this->_conection = 'mysql:host='.self::_host.';dbname='.self::_db;
if(!isset($this->_conecta) or isset($this->_conecta)&&$this->_conecta==null){
//LÓGICA PHP
try{
$this->_conecta = new PDO($this->_conection,self::_user,self::_pass);
$this->_conecta->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
}catch(PDOexception $error){
echo $error->getMessage();
}
}}//FECHA FUNÇÃO START
/*--------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------*/
public function __destruct(){
$this->_conecta=NULL;
unset($this->_conecta);
}}//FECHA CLASSE
?>
no caso para funcionar esse Pconect eu deveria deixar assim?
//METODO DE CONEXAO PDO
protected function Start(){
//CONEXÃO
$this->_conection = 'mysql:host='.self::_host.';dbname='.self::_db;
if(!isset($this->_conecta) or isset($this->_conecta)&&$this->_conecta==null){
//LÓGICA PHP
try{
$this->_conecta = new PDO($this->_conection,self::_user,self::_pass,array(
PDO::ATTR_PERSISTENT => true
));
$this->_conecta->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
}catch(PDOexception $error){
echo $error->getMessage();
}
}}//FECHA FUNÇÃO START
Minhas classe fica como extend dela, ou devo fazer diferente?
se tiver algo que eu esteja errando.. ou que eu poderia fazer melhor me avisem, por favor.
e só para explicar como eta funcionando ele:
/// exemplo se eu estancio uma objeto assim ele cria uma conexão nova e utiliza durante o processo do objeto;
$teste = new tabelaUm;$countTeste=$teste->getCount();
$if($countTeste<3){
$teste->Insert($Anuncio,$usuario);
$teste->IDdo Anuncio();
}$countTeste=$teste->getCount();
$if($countTeste<3){
$teste->Insert($Anuncio,$usuario);
$teste->IDdo Anuncio();
}//nao seria mais vantajoso se ele fizer-se só uma conexão usar-se durante todos os objetos e no final fexa-se a mesma?
>
porem a cada Objeto ele faz uma nova conexão, e no final finaliza a mesma.. só que eu estava pensando isso nao iria pejudicar o desempenho do site?
Sim, muito.
>
Minhas classe fica como extend dela, ou devo fazer diferente?
se tiver algo que eu esteja errando.. ou que eu poderia fazer melhor me avisem, por favor.
Deve fazer diferente. Utilize composição e agregação
A classe conecta, você utiliza de composição para o uso da PDO, o que está correto. Para seu objetos de consulta (model/DAO/ORM) utilize de agregação.
Por exemplo, eu posso o objeto de acesso a dados UsuarioDAO, ele serve para somente para acessar os dados de um usuário no SGBD e utiliza uma conexão. Ele não é uma conexão e não será somente ele a utilizar conexão. Isso já define que não estamos falando de herança(extends) e nem de composição. Isso é uma agregação.
Vamos ao meu DAO com base na sua conecta. Não vou muito afundo, pois o João Batista Neto da uma excelente aula neste tópico
class UsuarioDAO {
private $connection;
public function __construct(Conexao $conexao) {
$this->connection = $conexao;
}
public function select() {
/** código referente ao select **/
}
}para o seu uso, basta passar a Conexao e usufruir dela:
$conexao = new Conexao();
$usuarioDAO = new UsuarioDAO($conexao);Você poderá utilizar um Registry, em conjunto, para manter disponível essa conexão em qualquer lugar da aplicação, evitando criar várias conexões.
e aproveitar que estamos falando de conexao.. meu DB está apresentando isso.
SQLSTATE[HY000]: General error: 1467 Failed to read auto-increment value from storage engine
esquisito né?
>
Sim, muito.
Deve fazer diferente. Utilize composição e agregação
A classe conecta, você utiliza de composição para o uso da PDO, o que está correto. Para seu objetos de consulta (model/DAO/ORM) utilize de agregação.
Por exemplo, eu posso o objeto de acesso a dados UsuarioDAO, ele serve para somente para acessar os dados de um usuário no SGBD e utiliza uma conexão. Ele não é uma conexão e não será somente ele a utilizar conexão. Isso já define que não estamos falando de herança(extends) e nem de composição. Isso é uma agregação.
Vamos ao meu DAO com base na sua conecta. Não vou muito afundo, pois o João Batista Neto da uma excelente aula neste tópico
class UsuarioDAO {
private $connection;
public function __construct(Conexao $conexao) {
$this->connection = $conexao;
}
public function select() {
/** código referente ao select **/
}
}para o seu uso, basta passar a Conexao e usufruir dela:
$conexao = new Conexao();
$usuarioDAO = new UsuarioDAO($conexao);Você poderá utilizar um Registry, em conjunto, para manter disponível essa conexão em qualquer lugar da aplicação, evitando criar várias conexões.
perfeito, mas vem uma duvia sobre esse registro... ele salva o arquivo aonde?
tipo teoricamente ele é a mes coisa do q você passou acima.. nao é?
>
Sim, muito.
Deve fazer diferente. Utilize composição e agregação
A classe conecta, você utiliza de composição para o uso da PDO, o que está correto. Para seu objetos de consulta (model/DAO/ORM) utilize de agregação.
Por exemplo, eu posso o objeto de acesso a dados UsuarioDAO, ele serve para somente para acessar os dados de um usuário no SGBD e utiliza uma conexão. Ele não é uma conexão e não será somente ele a utilizar conexão. Isso já define que não estamos falando de herança(extends) e nem de composição. Isso é uma agregação.
Vamos ao meu DAO com base na sua conecta. Não vou muito afundo, pois o João Batista Neto da uma excelente aula neste tópico
class UsuarioDAO {
private $connection;
public function __construct(Conexao $conexao) {
$this->connection = $conexao;
}
public function select() {
/** código referente ao select **/
}
}para o seu uso, basta passar a Conexao e usufruir dela:
$conexao = new Conexao();
$usuarioDAO = new UsuarioDAO($conexao);Você poderá utilizar um Registry, em conjunto, para manter disponível essa conexão em qualquer lugar da aplicação, evitando criar várias conexões.
perfeito, mas vem uma duvida sobre esse registro... ele salva o arquivo aonde?
tipo teoricamente ele é a mes coisa do q você passou acima.. nao é?
Não entendi muito bem a sua pergunta, mas para eventuais esclarecimentos sobre o Registry, vai encontrar nessa thread:
Excelente explicação do Gabriel. No meu caso, eu faço o seguinte:
<?
class UserGateway{
private $stm;
public function __construct(){
$this->stm = new Factory(new StatementPDOMySQL());
#### Aqui, posso agregar outros objetos, tais como:
# StatementPDOPosgreeSQL,
# StatementMySQL, StatementPostgreSQL (para functions nativas)
}
public function dataSelect(){
#### code ####
return $this->stm->executeQuery(array(...));
}
}
?>>
Não entendi muito bem a sua pergunta, mas para eventuais esclarecimentos sobre o Registry, vai encontrar nessa thread:
cara esta apresentando esse erro:
Fatal error: Call to undefined method Conexao::prepare() in D:\wamp\www\site_perfeito\Protected\Library\Padroes\BaseBD.php on line 41
nao sei pq, pque testei e esta pegando a conexao certinho; =S
Na verdade, pra você usar o prepare, é necessário acessá-lo pelo objeto que cria sua conexão, exemplo:
<?
class Conn{
private $conn;
public function connect($sql){
$this->conn = new PDO('...');
$prepare = $this->conn->prepare($sql);
try{
$prepare->execute();
}catch(PDOException $e){
echo $e->getMessage();
}
}
}
?>>
cara esta apresentando esse erro:
Fatal error: Call to undefined method Conexao::prepare() in D:\wamp\www\site_perfeito\Protected\Library\Padroes\BaseBD.php on line 41
nao sei pq, pque testei e esta pegando a conexao certinho; =S
achei o erro mesmo retornando a variável ele estava pegando o objeto inteiro;
>
Na verdade, pra você usar o prepare, é necessário acessá-lo pelo objeto que cria sua conexão, exemplo:
<?
class Conn{
private $conn;
public function connect($sql){
$this->conn = new PDO('...');
$prepare = $this->conn->prepare($sql);
try{
$prepare->execute();
}catch(PDOException $e){
echo $e->getMessage();
}
}
}
?>sim.. tava tudo certo.. mas nao tava passando só a variavel de conexao tava passando o objeto inteiro.. aí eu corrigi isso. xD
>
Não entendi muito bem a sua pergunta, mas para eventuais esclarecimentos sobre o Registry, vai encontrar nessa thread:
entao tipo esse registre funciona como um backup porem funciona só na aplicação local, se você atualizar a pagina ou ir para outra será criado uma nova conexão e como esta ativo o Persist, ela nao desligará correto?
a pergunat se teria como fazer algo para usar durante todo processo de navegação só uma conexão.
>
so você deseje utilizar uma pconnect com PDO, você deve atribuir a constante ATTR_PERSISTENT. Seria o seguinte:
$conn = new PDO("mysql:host=localhost;dbname=basename", 'root' , 'password' , array(PDO::ATTR_PERSISTENT => true));Cara hoje acordei e pensei uma coisa tipo, se ele vai persistir na conexao eu poderia deixar já como extend das outras
pelo fato de manter uma só conexao. concorda?
Apesar de estarmos falando sobre pool de conexão utilizando pconnect, preciso lhe "falar umas verdades".
1º - Não é recomendável o uso de conexões persistentes, evite-as (com ou sem pool, não é recomendável);
2º - Não é só o caso de duplicar a conexão (ou não). Também duplicará as classes, criará redundâncias inúteis e maior consumo de memória;
3º - Ela **não é** uma conexão. Nesse caso não cabe à herança;4º - Leia sobre Liskov Substitution Principle.
A herença (extends) cabe quando uma sub-classe é a super-classe com "algo a mais".
O exemplo clássico é de uma pessoa.
- Pessoa é a **classe base**;
- PessoaFisica e PessoaJuridica são as **especializações**;Um model/ORM/DAO não é uma conexão, somente utiliza uma. Portanto, não cabe à herança.
>
Apesar de estarmos falando sobre pool de conexão utilizando pconnect, preciso lhe "falar umas verdades".
1º - Não é recomendável o uso de conexões persistentes, evite-as (com ou sem pool, não é recomendável);
2º - Não é só o caso de duplicar a conexão (ou não). Também duplicará as classes, criará redundâncias inúteis e maior consumo de memória;
3º - Ela **não é** uma conexão. Nesse caso não cabe à herança;4º - Leia sobre Liskov Substitution Principle.
A herença (extends) cabe quando uma sub-classe é a super-classe com "algo a mais".
O exemplo clássico é de uma pessoa.
- Pessoa é a **classe base**;
- PessoaFisica e PessoaJuridica são as **especializações**;Um model/ORM/DAO não é uma conexão, somente utiliza uma. Portanto, não cabe à herança.
entendo, eu usei o registre como você falou mas de forma diferente.. tipo...
eu executo a classe conexão e nela coloca o valor na classe registre.
e depois na claque query eu peço para recuperar o valor do registre.
ao inves de fica colocando em cada objeto coloquei direto na classe base de todo o crud das tabelas.
você acha que fiz certo?
pq sem ele disponibilizando as variáveis... a aplicação fica mais rápida... mas é mais trabalhosa. ja ele é mais facil. xD.
quando a conexao persistente.. aumentou muito a velocidade do site.. mas ela nao encerra as mesma.. tipo sem persistente ele demora mais porem encerra todas. ja com ele é muito rapido porem nao encerra.. =S
quanto a explicação de extends antes eu havia feito as seguintes classes..
o sinal -> vaiindicar a a proxia é filha;
conexao->query->crud->tabelaX
conexao->query->crud->tabelaY
agora ficou.
Conexao
query->crud->tabelaX
query->crud->tabelaY
>
entendo, eu usei o registre como você falou mas de forma diferente.. tipo...
eu executo a classe conexão e nela coloca o valor na classe registre.
e depois na claque query eu peço para recuperar o valor do registre.
ao inves de fica colocando em cada objeto coloquei direto na classe base de todo o crud das tabelas.
você acha que fiz certo?
De que forma você inclui? Precisaria ver.
quando a conexao persistente.. aumentou muito a velocidade do site.. mas ela nao encerra as mesma.. tipo sem persistente ele demora mais porem encerra todas. ja com ele é muito rapido porem nao encerra.. =S
Dependendo da quantidade de conexões com o banco, uma conexão sempre ligada vai te limitar o número de usuários.
>
De que forma você inclui? Precisaria ver.
Mudei, eu estudei o registre e consgui entender como ele funciona.. com isso eu deixei a função de retornar como statica.
ficou assim, a classe Conexao cria o Obj PDO.
a Classe tabelaUM é extend da classe Crud e tem todas as Querys da tabelaUM.
e a classe Crud é extend da classe Query(que nada mais é q a base para a query).
Obs: antes a minha classe Crud funcionava como se fosse um framework, só precisava passar campos e valores e dizer oq que queria q fizer-se q ela fazia automática, mas achei q iria sobrecarregar o server pois a classe tinha muita condição e também gerar trabalho pro server por preguiça de construir as SQL seria burrice. então eu mudei ela e a parte de Select,Update,eu passo o sql manual, o update por ser simples ele construi.. e o Inser ficou top, ele recebe o array e inseri automaticamente e fiz um insert múltiplo que inseri varios dados em um unico sql e exute.
*se interessar eu posto ela pra você ver**, eu testei e o ganho de desempenho foi bom com esse tipo de insert xD;*
>
Dependendo da quantidade de conexões com o banco, uma conexão sempre ligada vai te limitar o número de usuários.
é eu encontrei uma redação sobre conexões persistente e apesar de ser rapida tem esse problema do limite.
Cara valeu mesmo por tirar minhas duvidas... sou meio burrinho, mas com a ajuda do pessoal consegui entender melhor sobre POO e Conexões , encontrar e corrigir muitos erros meu nos meus algorítimos!
Eu acho que esse tópico já está tomando outro rumo que não o de Pool de Conexões.
Se concordarem, proponho uma divisão dele.
Eu não ia opiniar sobre o assunto porque não entendi direito mas, não seria um caso simples de Registry não?
>
[...]não seria um caso simples de Registry não?
Para um único usuário acessando o sistema, sim. Para multi-usuários, não. É basicamente como o pool de impressão. Você envia documentos para imprimir, de diversos computadores, e eles serão impressos na ordem que foram recebidos. O SGBD já não, ele recebe os processos e executa-os em "paralelo", o primeiro que terminar terá seu resultado retornado.
Antes de existir o pool de impressão, acontecia as "impressões paralelas", vários arquivos sendo impressos ao mesmo tempo. Uma hora saia uma folha de um arquivo, duas de outro, mais uma do primeiro. O pool foi criado para resolver isso.
Em um SGBD, eu vejo como uma "fila" de processos, você vai enfileirando as consultas realizando uma de cada vez. Como o processo é priorizado, sua execução é extremamente rápida. Se existirem muitos processos, são enfileirados e aguardarão sua execução. Isso é processamento em batelada(batch) e é útil, ao meu ver, em sistemas do mesmo tipo(batch), onde não há interação do usuário e o sistema necessita da resposta para continuar o processo. Não vou adentrar sobre os tipos de processamento, pois ai já é outra história.
Eu, particularmente, gosto do trabalho paralelo dos SGBDs. "Processamento paralelo" (que não é tão paralelo assim) foi um grande avanço na tecnologia dos SOs.
Beleza, já clareou um pouco.
Eu nunca mexi com isso mas possivelmente o Gearman resolveria esse problema. Tenho poucas informações sobre seu funcionamento mas tudo indica que bastaria adicionar o IP/Nome do Servidor responsável por esse Pool.
E ao invés de os clientes executarem as queries diretamente eles enviariam informações para que o pool adicionasse uma tarefa.
Hum, acho que o PDO já faz esse trabalho para você, basta criar objeto PDO passando seus parametros. Mas olha, não tenho certeza desta afirmação.
Mas to percebendo que está complicando as coisas. Não é mais fácil somente criar seu objeto de conexão, e deixar a aplicação trabalhar normalmente? O PDO já faz tarefas de tratar conexões sem sobrecarregar o servidor.