Array
(
)

otimizar acesso e consultas ao IB

Vitor^_^
   - 02 jan 2006

Tenho um sistema cliente/servidor, com o banco de dados Firebird 1.5 na web.

Otimizei ao máximo as queries, não existe nenhum ´select * ´ , uso clientdataset.

O que acontece: Ao abrir uma tabela pela primeira vez, fica muuuito lento, chega a demorar 2 minutos. Mas, ao abrir novamente as mesmas tabelas, é bem rápido, não tem problema nenhum.

Como eu posso resolver isso?


Peninha
   - 02 jan 2006

Ola amigo, posta o código da sua consulta para que possamos te ajudar?
Erivan.


Vitor^_^
   - 02 jan 2006

São várias consultas, qualquer uma delas é a mesma coisa, demora pra abrir na primeira e abre rápido na segunda.

Eu uso select * somente quando vou cadastrar um novo registro, porque eu tenho que preencher todos os campos. aí eu faço tipo:

select * from CLIENTES
where CodCli = :cod

ponho esse :cod aí, porque se for qualquer coisa <> de 0, ele abre o cds pra cadastrar ocliente. Se for nada, ou um valor inexistente, ele não traza nada. (então eu acho que uma query q não traz nada seria rápida), e se for um número existente, aí tudo bem, ele traria tudo. Mas não traz porque nunca é passado um número nessa tela, pois ela é usada somente para cadastro, não para consulta. as de consulta são assim:

select codcli, razao, from clientes
where codcli = :cod


Edilcimar
   - 02 jan 2006

talvez esteja demorando na primeira vez pelo fato do bd estar fechado no servidor, e na segunda vc já o abriu, para testar deixe o bd aberto no servidor


Vitor^_^
   - 02 jan 2006

você diz o serviço rodando? está sempre rodando.

O bd é aberto no momento da abertura do executavel. só que, depois do bd aberto, a primeira consulta demora, a segunda já é mais rápida.

será que tem algo a ver com cache?


Edilcimar
   - 02 jan 2006

Tem índice? Uma pesquisa com índice é mais rápida que outra sem, se não tem a primeira vez ele pode realmente criar um em cache e depois vai buscar no cache e aí é mais rápido, mas se a 2ª pesquisa demorar muito, pode sumir do cache e volta a ser lenta


Vitor^_^
   - 02 jan 2006

Já tenho os indices criados.

basta criar o indice que aí qualquer select que você fizer usando e ordenando pelo campo indexado fica mais rápido, certo? É só fazer um select normal mesmo, não é?


Edilcimar
   - 02 jan 2006

é, vc pode inclusive colocar um timer e fazer a pesquisa com e sem índice para verificar a diferença de tempo


Vitor^_^
   - 02 jan 2006

então, meu bd já tem indices. Eu sei que é mais rápido. Para usar o bd em redes locais nunca tive problemas, mas usando na web, para diversas filiais, é diferente. Deve ter algum outro esquema de otimização.


Edilcimar
   - 02 jan 2006

vc precisa da informação online na web?


Vitor^_^
   - 02 jan 2006

sim, porque o banco de dados é acessado por mais de 20 lojas.

Alguns cadastros são gerais e outros são separados por lojas, mas todas acessam tudo.


Edilcimar
   - 02 jan 2006

bem aí então vc tem que arranjar um link mais rápido, que não vai ter jeito não, pois hoje vc tem 20 lojas com 10.000 clientes amanhã terá 50 lojas com 100.000 clientes, isto sem contar a tabela de produtos, a de movimentação, duplicatas e etc


Vitor^_^
   - 02 jan 2006

está lento mesmo na loja que tem o link mais alto, tipo de 600 kbps pra cima.

O problema não é o link, porque como eu disse, só é lento na primeira consulta, as demais são rápidas, dependendo da consulta, posso até arriscar que parecem locais.


Titanius
   - 02 jan 2006

Olá vitor^_^

Também tive este problema, so consegui resolver usando 3 camadas com DCOM, aí consegui acessar via internet, fora isso é impossível mesmo...


[]s


Edilcimar
   - 02 jan 2006

é, tente o que o titanius falou, eu não tenho mais dicas a respeito


Vitor^_^
   - 02 jan 2006

Oi titanius, já li os seus tópicos a respeito do assunto nesse forum, mas eu acho que migrar minha aplicação para 3 camadas seria meio doloroso, pois ele não foi feita pensando nisso e não está preparada.

É muito difícil? Por onde eu começo? Me disseram que dCom é problemático, e que com corba ou Sockets é melhor, mas sinceramente eu não conheço nehuma das várias formas.


De qualquer forma, um dia eu terei que fazer essa migração mesmo, mas por enquanto, meu problema é o seguinte: Só é lerdo na primeira consulta a uma tabela, todas as outras são rápidas. Se desse pra melhorar pelo menos isso até terça, depois agente pensa em 3 camadas.


Ipc$
   - 02 jan 2006

Uma consulta que demora 2 minutos é muito tempo mesmo. Será que não tem algum problema com o banco ? A tabela é muito grande em registros ou muito larga em campos ?
Se não houver problemas com o banco ou com o software de acesso, acho que um jeito de contornar isso é vc fazer essa primeira consulta numa thread logo quando o aplicativo entra no ar.


Vitor^_^
   - 02 jan 2006


Citação:
Uma consulta que demora 2 minutos é muito tempo mesmo. Será que não tem algum problema com o banco ? A tabela é muito grande em registros ou muito larga em campos ?
Se não houver problemas com o banco ou com o software de acesso, acho que um jeito de contornar isso é vc fazer essa primeira consulta numa thread logo quando o aplicativo entra no ar.


As duas coisas ^^

mas todos os atributos das entidades estão certinhos, não tem o que normalizar. Só umas coisinhas que fariam pouca diferença, mas, por exemplo, uma consulta que da primeira vez demora 1 ou 2 minutos, na segunda vez demora de 90 a 5000 milissegundos.

Como eu faria o esquema da thread? vou testar isso, valew!


Ipc$
   - 02 jan 2006

Uma thread seria vc fazer a primeira consulta em background sem que o cliente perceba. Defina um objeto que descenda de TThread, instancie esse objeto no onCreate e em seu método execute vc faz a consulta e depois finaliza a thread. Com isto a consulta ´fantasma´ estaria sendo feita sem a intervenção do usuário. Já não saberia te responder como ficaria a preformance se nesses primeiros dois minutos o usuário fizesse uma consulta também. Só testando.