Lentidão em Aplicação Delphi 2010+DbExpress!!
Olá Amigos do forum. Por favor não se espantem com o Título do tópico. Resolvi colocar este título por que estou com esse problema e procurei a solução em diversos sites na NET e até agora nenhuma solução plausível para o problema.
Meu caso é o seguinte:
1 - Estou desenvolvendo uma aplicação para a paróquia da minha cidade, é um sistema de controle de Romarias, batizado com o nome de SiSRomaria (Sistema de Gerenciamento de Romarias). Nele, estou usando para desenvolve-lo as seguintes ferramentas:
RadStudio 2010 + A galera do DataAcess(DataSetProvider+ClienteDataSet+DataSource)+Firebird 2.1 usando o driver NATIVO do RadStudio.
2 - Ai vem o dilema: Sempre desenvolvo minhas aplicações programando diretamente no Delphi (dbEdits) e no Banco utilizo alguns recursos como (Trigger para geração de código automático+Viewers para Relátórios+Domínios, etc). Nunca tive problemas de lentidão dessa forma, até por que nunca peguei uma empresa que tivesse um perfil de quantidade de registros tão grande como esse projeto de Romaria. Ocorre que desde quando a quantidade de registros chegou na casa dos 50 regs. o banco vem caindo de desempenho/velocidade. Procurei em vários sites e muitos detonaram essa forma de programação por vários motivos.. por que traz muitos registros, etc.. eu e outros colegas achamos uma babozeira. Claro que o OPERADOR do sistema vai quere ver os registros na tela, fazer pesquisa, etc.
3 - Umas das dicas interessantes foi de alterar a propriedade PacketRecords do ClienteDataSet para 20 ou 50, isso quer dizer que a tabela só vai trazer 20 ou 50 registros por vez e, a medida que passamos os registros (dbnavigator/dbgrid) os outros registros vão sendo chamados. Isso resolveu em parte, melhorou uns 50% +-.
4 - A outra opção: Tive a idéia de mudar para ADO, pois programo em SQLSERVER tb. só que o RadSTudio não possui um driver de comunicação direta com o firebird, então consegui um DRIVER ODBC para firebird 2.1 chamado de Firebird_ODBC_2.0.0.151_Win32.. ai meus problemas começaram a diminuir. A velocidade de acesso disparou.. o acesso ficou muito rápido melhorou, no total, uns 70% mas bem aquem dos outros projetos que fiz com Firebird+DbExpress e quando usava o Delphi7 para Driver UIBFirebird. Resumindo: Mudei tudo para ADO mas continuo usando o trio do DataAcess.
Gostaria de saber dos colegas se tem mais alguma coisa que devo fazer pra melhorar o desempenho do meu sistema. E bom frizar que o acesso ao banco pelo IBExpert ou IbConsole é super rápido, tando em inserts,selects,updates etc.. o problema é mesmo no acesso a esses dados pelo DELPHI2010. Não vale a dica pra jogar a programação toda pro banco, até por que imaginem a quantidade de empresas que trabalham da mesma forma que eu? O SINDIONIBUS (Sindicato de Transportes Urbanos) aqui de Fortaleza trabalha dessa forma (DbEdits). Tenho colegas lá e o Analista Chefe de lá é meu amigo.. Então, não não é totalmente verdade isso, de que programar diretamente no Delphi, pode deixar a aplicação lenta. Os drivers de acesso servem pra isso, pra resolver esse problema e não deixar isso pro programador.
Aproveito também para pedir a sugestão dos Srs, por que vou ter que desenvolver outra aplicação do mesmo porte. Não posso usar SQLSERVER pq a empresa não quer pagar a licença e não quer colocar PIRATA, então tem que ser um SGBD rápido, confiável, gratuído q tenha o mínimo de suporte.
Abraço a todos e obrigado pela atenção!!
Meu caso é o seguinte:
1 - Estou desenvolvendo uma aplicação para a paróquia da minha cidade, é um sistema de controle de Romarias, batizado com o nome de SiSRomaria (Sistema de Gerenciamento de Romarias). Nele, estou usando para desenvolve-lo as seguintes ferramentas:
RadStudio 2010 + A galera do DataAcess(DataSetProvider+ClienteDataSet+DataSource)+Firebird 2.1 usando o driver NATIVO do RadStudio.
2 - Ai vem o dilema: Sempre desenvolvo minhas aplicações programando diretamente no Delphi (dbEdits) e no Banco utilizo alguns recursos como (Trigger para geração de código automático+Viewers para Relátórios+Domínios, etc). Nunca tive problemas de lentidão dessa forma, até por que nunca peguei uma empresa que tivesse um perfil de quantidade de registros tão grande como esse projeto de Romaria. Ocorre que desde quando a quantidade de registros chegou na casa dos 50 regs. o banco vem caindo de desempenho/velocidade. Procurei em vários sites e muitos detonaram essa forma de programação por vários motivos.. por que traz muitos registros, etc.. eu e outros colegas achamos uma babozeira. Claro que o OPERADOR do sistema vai quere ver os registros na tela, fazer pesquisa, etc.
3 - Umas das dicas interessantes foi de alterar a propriedade PacketRecords do ClienteDataSet para 20 ou 50, isso quer dizer que a tabela só vai trazer 20 ou 50 registros por vez e, a medida que passamos os registros (dbnavigator/dbgrid) os outros registros vão sendo chamados. Isso resolveu em parte, melhorou uns 50% +-.
4 - A outra opção: Tive a idéia de mudar para ADO, pois programo em SQLSERVER tb. só que o RadSTudio não possui um driver de comunicação direta com o firebird, então consegui um DRIVER ODBC para firebird 2.1 chamado de Firebird_ODBC_2.0.0.151_Win32.. ai meus problemas começaram a diminuir. A velocidade de acesso disparou.. o acesso ficou muito rápido melhorou, no total, uns 70% mas bem aquem dos outros projetos que fiz com Firebird+DbExpress e quando usava o Delphi7 para Driver UIBFirebird. Resumindo: Mudei tudo para ADO mas continuo usando o trio do DataAcess.
Gostaria de saber dos colegas se tem mais alguma coisa que devo fazer pra melhorar o desempenho do meu sistema. E bom frizar que o acesso ao banco pelo IBExpert ou IbConsole é super rápido, tando em inserts,selects,updates etc.. o problema é mesmo no acesso a esses dados pelo DELPHI2010. Não vale a dica pra jogar a programação toda pro banco, até por que imaginem a quantidade de empresas que trabalham da mesma forma que eu? O SINDIONIBUS (Sindicato de Transportes Urbanos) aqui de Fortaleza trabalha dessa forma (DbEdits). Tenho colegas lá e o Analista Chefe de lá é meu amigo.. Então, não não é totalmente verdade isso, de que programar diretamente no Delphi, pode deixar a aplicação lenta. Os drivers de acesso servem pra isso, pra resolver esse problema e não deixar isso pro programador.
Aproveito também para pedir a sugestão dos Srs, por que vou ter que desenvolver outra aplicação do mesmo porte. Não posso usar SQLSERVER pq a empresa não quer pagar a licença e não quer colocar PIRATA, então tem que ser um SGBD rápido, confiável, gratuído q tenha o mínimo de suporte.
Abraço a todos e obrigado pela atenção!!
Marcus Cordeiro
Curtidas 0
Respostas
Marco Salles
09/02/2012
Praticamente na questão da velocidade voce fez tudo ..
Pode talves não utilizar instruções como Select * From e sim trafegar somentes os campos
pertinentes Select CampoA , CampoB ,..., From
Utilizar tb clausua Where meljora e muito e por fim criar Indices na Base de dados
Quanto ao Novo aplicativo pq não continua no Próprio Firebird ????
Pode talves não utilizar instruções como Select * From e sim trafegar somentes os campos
pertinentes Select CampoA , CampoB ,..., From
Utilizar tb clausua Where meljora e muito e por fim criar Indices na Base de dados
Quanto ao Novo aplicativo pq não continua no Próprio Firebird ????
GOSTEI 0
William
09/02/2012
Estranho essa lentidão, desenvolvo minhas aplicações com firebird 2.5 + Delphi 2010, até hoje nenhum dos meus clientes reclamou de tal lentidão, não DBEdit uso Edit pode parecer um mero detalhe mas junto com outras melhorias como carregar o DataModule somente qdo as tela de cadastro são acessadas, todos SQLQuery ficão fechados etc.....
GOSTEI 0
Marcus Cordeiro
09/02/2012
Pois é.. estranho mesmo.. sempre usei do Delphi7 e agora do RadStudio 2010 e nunca tive probelam.. e não mudei uma vígula da maneira de programa... pelo contrário, aprendi mais técnicas de implementação. Eu fiz outra coisa pra testar.
1 - Fiz um backup do meu banco no firebird 2.1.
2 - Desinstalei o 2.1 e instalei o 2.5;
3 - Depois restaurei o backup.. se tiver tido alguma melhora foi imperceptível...
Mas vou ficar aguardando mais dicas dos colegas pra ver!!
Obrigado pela opinião!!
1 - Fiz um backup do meu banco no firebird 2.1.
2 - Desinstalei o 2.1 e instalei o 2.5;
3 - Depois restaurei o backup.. se tiver tido alguma melhora foi imperceptível...
Mas vou ficar aguardando mais dicas dos colegas pra ver!!
Obrigado pela opinião!!
GOSTEI 0
Luiz Moura
09/02/2012
Pode se que o que vou escrever você já esteja usando, mas como você não tocou no assunto aqui vai.
Quando estava fazendo testes para escolher qual usar Firebird, PostGreSQL e mySql, comprei livros sobre todos eles no final no caso do sistema que estava desenvolvendo, era fundamental um BD de fácil manutenção e instalação e nisto o Firebird na versão Embarcada é campeão.
Só que nos meus testes o Firebird estava muito lento, entrei em contato com o fabricante do drive que eu uso o da Devart.
E me orientaram a fazer controle de transação em tudo, porque nenhum dos livros que tenho informa, mas é fundamental para o desempenho do Firebird.
Amigo falo, é inacreditável.
Já estava desistindo de usar o Firebird mas veja isto....
O teste de inclusão e alteração massiva de dados que preparei, passou de 38 minutos para inacreditávei 223 segundos.
É isto aí o Firebird com até os select encapsulado em uma transação tipo ReadCommitted, passa a fazer jus ao nome, voa!!!
Quando estava fazendo testes para escolher qual usar Firebird, PostGreSQL e mySql, comprei livros sobre todos eles no final no caso do sistema que estava desenvolvendo, era fundamental um BD de fácil manutenção e instalação e nisto o Firebird na versão Embarcada é campeão.
Só que nos meus testes o Firebird estava muito lento, entrei em contato com o fabricante do drive que eu uso o da Devart.
E me orientaram a fazer controle de transação em tudo, porque nenhum dos livros que tenho informa, mas é fundamental para o desempenho do Firebird.
Amigo falo, é inacreditável.
Já estava desistindo de usar o Firebird mas veja isto....
O teste de inclusão e alteração massiva de dados que preparei, passou de 38 minutos para inacreditávei 223 segundos.
É isto aí o Firebird com até os select encapsulado em uma transação tipo ReadCommitted, passa a fazer jus ao nome, voa!!!
GOSTEI 0