Economizando Requisições ao Banco de Dados

[Uélio Nobre 0]

What's Up!

 

E ai pessoal...

Recentemente o trabalho me colocou uma calça justa(homem não usa saia!).

O lance era o seguinte: Uélio, será que isso vai suportar seis mil clientes conectados?

 

Comecei a imaginar fato que aconteceu comigo há alguns anos atrás. Um cliente me ligou as dez horas da noite me perguntando o porque a página dele estava fora do ar!

 

Ai pensei (ou tentei pensar, já que esse horario aqui no Ceará já tem muita gente dormindo).

- Oxe, o negocio estava rodando direitinho.

 

Dai, então fui ver o que tinha acontecido com a bendita página do infeliz com insônia.

Quando digito o endereço do rapaz, a página me retorna: Too many connections....

 

 

Deste dia em diante resolvi tentar buscar uma solução (ou então burlar isso!).

E foi horas e horas no banheiro, mais horas e horas no banheiro....

Dias foram passando e acabou no esquecimento.

 

Mas, o destino é muito cruel e resolver revivar o que a minha cabeça tinha matado no esquecimento. O velho problema de requisições ao banco de dados.

Bom, hoje mais maduro (pelo menos em relação as linhas de codigo que escrevo), encontrei a solução direitinho.

 

Pessoal, sei que isso é chato, mas, que é que nunca viu o mesmo post em centenas de blogs?

E que as vezes não levam o nome de seu criado (decepção).

 

Bom. [Voltando ao assunto..]

Quando se pensa em "Economizar requisições ao Banco de Dados" eu quero uma solução para utiliza-lo menos. E não otimizar as minhas querys de SQL.

Se eu quiser postar algo como "Otimizar requisições SQL ao Banco de Dados", ai sim, eu teria que formar uma logíca fodelastíca pra otimizar as minhas intruções SQL.

 

Mas....

Como eu quero utiliza-lo menos, eu pensei em uma maneira de criar meus aplicativos (ou sistemas, tanto faz. Você entendeu) utilizando a velha a boa e companheiro e........ XML.

 

Ei, psiu!

Num corra não.

É isso mesmo que você ouviu. XML!

 

Bom, eu sei que muita gente já pensou nisso.

Mas, o que importa é que já pensaram e não compartilharam ainda, entende?

Pelo menos não desta forma.

 

Criei uma imagem de representação simples, que vale para a maioria das linguagens de programação (não sei programar em todas as linguagens pra saber).

 

Agora, estou fazendo a minha parte.

Espero que vocês achem o que irão ver útil tanto quanto é pra mim.

 

Clique aqui

 

Obrigado pela atenção - desculpa pelo drama!

[romabeckman 0]

Olá Uélio Nobre, procure pro procedures e view indexada, isso poderá melhorar o desempenho com banco de dados.

Outra idéia é utilizar capas, onde você usa páginas HTML préviamente carregada. Em páginas repetitivas você poderá gerar HTML das páginas e realizar chamadas sem a necessidade de consulta em banco de dados e utilizar o crontab para atualizar as páginas. Estas são algumas idéias. Espero ter ajudado.

[André Severino 3]

Kra as query realmente estão 'relacionadas' com o desepenho de um servidor, mas essa questão do Too many connections é problema com o código em si e não com o 'servidor', kra recentemente peguei um sistema e apenas começei a implementar funções nele (cadastro, newsletters, área do usuário e etc), e por incrivel que pareça após uns 3 meses de uso recebi este mesmo problema que você, o site estava fora do ar e aparecia a bendita mensagem 'Too many connections....'.

 

Sabe o que aconteceu? O outro programador deixo todas as conexões com o banco de dados em abertas ou seja 1 pessoa acessava e não era fechada a conexão com o acumulo de acessos simultaneos o servidor caiu.

 

O que eu fiz para resolver? Apenas 2 linhas de códigos.(liberar memoria e fechar a conexão)

$sql = mysql_query("SELECT * FROM usuario WHERE id = $id");

// Depois mais uma porrada de coisas
mysql_free_result(). // Liberar a memoria
mysql_close(). // Fechar a conexão

 

De numa pesquisada sobre o close e o free_result :thumbsup:

[Bruno Augusto 417]

Assim, todo seu tópico deu a entender que você encontrou o livrinho do Sean Connery em Indiana Jones e Última Cruzada.

 

Mas eu só vi foi uma imagem que representaria um diagrama de modelagem então...:

 

a ) Você está com o problema ainda e quer colaboração no desenvolvimento?

b ) Já desenvolveu toda a solução e quer compartilhar (smiley idiota)

c ) Quer me bater por não ter entendido? :P

[Uélio Nobre 0]

Não pessoal, vocês não entenderam.

O lance é economizar requisições ao banco de dados. Que neste caso e utilizando a XML.

Os tópicos que se encontram na WEB, somente fala a respeito de otimizações na estrutura SQL.

 

Um exemplo.

Tenho 22 tabelas em um determinado sistema.

Acessos diários de 3000 usuários.

 

Se planejassemos o sistema utilizando somente MySQL para armazenar dados. Então teriamos 66.000 requisições ao banco de dados + 3.000 conexões. Resultando em 69.000 requisições ao MySQL.

 

Agora, se utilizassemos para a interface do usuário alguns arquivos em formato XML, economizariamos muito dessas 69.000 requisições.

 

 

Exemplo.

22 tabelas no sistema

09 arquivos XML

Acessos diários de 3000 usuários.

 

Em requisições do usuario seria 22-9 = 13

Agora seria 13 * 3000 que resulta em 39.000.

Neste caso, economizariamos 27.000 requisições ao banco de dados. Entendeu?

 

 

Claro que muita gente sabe que a XML existe, assim como txt ou formatos próprios.

O que acontece que muita gente não usa, escorando somente no MySQL.

Não estou imperando para não usar o MySQL.

Estou mostrando o resultado da busca por "Otimizando requisições ao Banco de Dados".

 

Lembro-me a muito tempo atrás, acho que foi em 2004 que comecei a usar PHP & MySQL.

Houve um período (acho que uns 5 meses de utilização destas tecnologias) eu tinha um medo incrível de arrays.

Isso mesmo que você lêu, eu tinha medo de arrays.

 

Até o momente que precisei utilizar.

Ai ouvia uns rumores do tipo: Quem diz que é webdesigner e não sabe utilizar a ferramenta caneta. Não sabe o que está falando.

A partir daí encorajei-me: Se eu não sei usar um array, ainda não sou programador.

Depois dessa veio muitos e muitos pensamentos conflitantes deste gênero.

 

Até que fui perdendo o medo de pensar, achar que tudo estava nos foruns, na WEB. Pensar que tudo que se perguntar em um forum, logo mais a minha pergunta será respondida.

 

Ai tive uma dúvida na qual estavam demorando muito a me responderem.

Então pensei: A minha cabeça esta aqui pra quê?

 

Uau, a partir daí pude ver o inicio da linha do carretel da programação.

E cheguei a algumas conclusões tipo: Programar é expor em linhas de código a filosofia das coisas.

Outra: Se você não sabe pensar em como resolver um problema, não podemos nos insinuar programadores de computador.

 

Certo que as vezes, o negocio já vem mastigado, somente pra você escrever o que se pede. Mas para isso, aprendemos primeiro a pensar(antes de tudo a linguagem escolhida).

 

Bom. Sei que o tópico não é sobre mim. Mas, achei a experiencia boa pra contar, principalmente, para que está iniciando ou quem está em nível intermediario na sua linguagem de programação.

 

Hoje, estou aplicando meus conhecimentos em OO.

Não tenho muito o que postar por que ainda tenho muito o que escrever em OO.

Atualmente estou dando uma oportunidade a mim aprendendo Java. (Com o livro da 8ª edição da deitel, vocês conhecem)

 

Ops....

Voltando ao assunto original....

 

Sim pessoal, o lance de otimizar requisições ao servidor acho que é essa.

Podem conferir, {search in google about} "Otimizando requisições ao Banco de Dados".

Os caras falam somente de otimização de SQL's ante de envia-las ao servidor.

Mas, a buscar "Otimizando requisições ao Banco de Dados" neste caso é diminuir as requisições a base de dados.

 

Bom, espero que seja útil a algumas pessoas(uma só já esta bom, o que importa é que compartilhei!)

Obrigado pela atenção

 

Fui bem no drama? Brincadeira!

[André Severino 3]

Obrigado pelas dicas espostas Uélio, mas isso que você diz de otimizar as consultas com o sql através de um xml seria o que ?!

 

Porque assim a grosso modo estou pensando no seguinte - você teria que enviar uma requisição ao banco e retornar ao usuario em um xml e depois exibir esse resultado...

Na proxima consulta que o usuario fizer você verificaria se existe ja esse xml !?

 

Não entendi muito bem essa parada do xml, vou dar uma pesquisada no assunto, pois logicamente (na minha kbeça), eu pensando assim:

 

Faço requisição no banco - retorno no xml - exibo os registros

Na próxima requisição não vai ter que fazer a mesma coisa ?

Faço requisição no banco - retorno no xml - exibo os registros

 

Posso estar falando coisa errada, mas vou dar uma pesquisada... abraços e até mais :thumbsup:

[Uélio Nobre 0]

Não foi do jeito que você pensou.

Mas ou menos assim...

 

 

O Administrador...

 

01 - cadastra no MySQL

02 - gerar Arquivo *.xml

03 - quando o usuario necessitar de tal informação...

04 - busque no *.xml

 

 

Logo, economizamos em:

 

01 - Conexao com a Base de Dados

02 - redução de requisições ao Banco de Dados

 

 

Tome como o exemplo dos estados e dos municipios

Ao, invés de criar uma conexao com o banco, projetar a estrutura SQL, percorrer os dados para depois exibí-los.

Pode somente ler o arquivo *.xml

Entendeu?

 

O modo que você entendeu é muito redundante.

[William Bruno 1501]

Ainda estou achando pouco performático isso.

 

Que tal arquivos estáticos para cache?

gere arquivos .html das páginas que sofrerem poucas modificações.

 

O arquivo não existe. Na primeira requisição, você cria ele.

Dai em diante, todos os clientes solicitam este arquivo .html

 

Qndo algo for alterado no banco, delete este arquivo.

[André Severino 3]

Hum entendi agora, então isso significa que ao gerar uma consulta no banco de dados ele cria um arquivo .xml...

Olha estou achando isso um pouco estranho, porque como os dados mudam, geralmente vai ter que ficar atualizando direto estes arquivos(.xml) no servidor...

 

Mas é uma opção :thumbsup:

[Bruno Augusto 417]

Não sou especialista, mas não seria para isso que o NoSQL veio?

 

Porque eu vejo ele como um banco de dados, sem banco de dados e, mesmo não me aprofundando no assunto, vi que diferentes "bancos" NoSQL são mais velozes que outros para determinadas tarefas.

 

Pensando dessa forma, e programando maciçamente, acredito que bastaria criar uma série de handlers, um para cada "banco", todos eles implementando a mesma interface para garantir que os mesmos métodos estejam presentes em todos os handlers (e ainda proporcionar facilidade no polimorfismo) e usar cada um deles na situação mais cabível para tanto.

 

Atualmente, não uso "pra valer", mas tenho em meu sistema uma versão ligeiramente diferente do MongoHandler que o João Batista postou na sala de NoSQL.

[visitante_php 0]

ainda prefiro Singleton...