As conexões mysql não utilizadas retardam os scripts?

Estou no processo de escrever uma API para o meu site, juntamente com uma class bastante grande para processar todos os pedidos da API.

A maioria das páginas, se não todas as páginas do site, enviará pelo menos uma solicitação para a api na carga. A prioridade mais importante para este site é a eficiência e, consequentemente, um processamento de servidor muito rápido.

Estou, portanto, buscando um pouco de conselhos quando se trata de classs e certas funções PHP.

Em primeiro lugar, parece que a class que estou escrevendo provavelmente acabará sendo cerca de 3000 linhas de código. Se isso for inicializado em cada página, ignorando o fato de que apenas uma ou duas das funções dentro da class serão usadas por página, isso tornará a API muito mais lenta? Devo olhar para arquivos separados com extensões para a class para cada método de class?

Em segundo lugar, atualmente tenho todas as minhas conexões com os vários bancos de dados em arquivos separados dentro de um diretório. Dentro de cada conexão está a function mysql_pconnect (). No momento, eu só preciso desses arquivos quando necessário. Então, se o método precisar de uma conexão com o database x, então eu simplesmente coloco requer (conexão …) no método. É ruim include arquivos dentro de uma class?

Estou perguntando porque a única outra solução é exigir todas as conexões no topo da página para que a class possa acessá-las sem exigê-las para cada método. É por isso que eu gostaria de saber se ter várias conexões ao mesmo tempo, mesmo que não sejam usadas, está cobrindo tributação no servidor?

Então, três perguntas realmente:

  1. O início de uma class grande no início de cada página desacelera o tempo de execução do script, mesmo que apenas um método de class esteja sendo usado? Por que as pessoas usam ‘class extends class’?
  2. É ruim para ‘exigir arquivos ()’ dentro de uma class?
  3. As conexões não utilizadas em um database mysql desaceleram o tempo de execução de um script?

Não, uma conexão MySQL não utilizada não consumirá muito (se houver) o tempo da CPU, embora ocupe um pouco de memory para lidar com os vários bits de “estado” que devem ser mantidos por conexão.

No entanto, note que o protocolo de conexão do MySQL é realmente bastante “leve”. A manutenção de um conjunto de conexões persistentes parece atraente, mas o custo de estabelecer uma nova conexão já é muito baixo de qualquer maneira.

As conexões persistentes são uma solução rápida para resolver a sobrecarga de conexão, mas eles trazem problemas. O pior, sendo conexões abandonadas, pode deixar as conexões em um estado indeterminado (transactions em andamento, variables ​​/ configurações do servidor alteradas, etc …) e você pode facilmente criar deadlocks inadvertidos, a menos que seja muito cuidadoso.

Se você estiver escrevendo um api para servir os dados do seu db para várias partes do terceiro, você está melhor não deixando-os consultar o db, nem mesmo através de um serviço na web (a menos que você tenha mutações db do segundo ao segundo que essas terceiras partes precisam imediatamente)

Uma maneira melhor seria escrever arquivos xml em uma localização protegida e usar um serviço web para autenticar uma terceira parte e servir o (s) arquivo (s) xml. Em seguida, atualize o xml periodicamente.