Re-publicar quot;Guia de Performance Interbase / Firebirdq

Já agora se deletassem os artigos com dados corrompidos era otimo, para não tentarmos le-los.

[b:3c75ba2f94]Guia de Performance Interbase (I)[/b:3c75ba2f94] Por Peter Mc Leod Tradução: Cristiano de Favari Marcello Henrique da Costa Grec Este artigo tenta definir várias direções em como conseguir a melhor performance no Interbase. Antes de chegar aos aspectos que eu recomendaria no projeto de bancos de dados para atender às demandas de seus clientes, eu pediria que você lembrasse que geralmente os aspectos mais caros (na ordem) dos custos de um projeto são: 1. Desenvolvedores 2. Rede 3. Servidor Então, quando estiver priorizando seus recursos, mantenha os itens acima em mente. Também, um atalho tomado no começo (tal como não testar um banco de dados largamente povoado) sempre leva no mínimo três vezes mais tempo para reparar mais tarde, levando a custos no mínimo três vezes maiores. Desenvolvimento de Bancos de Dados ================================== Normalize seu Banco ------------------- Não interessa para qual banco de dados você esteja desenvolvendo, você tem que começar com um bom projeto. Assegure-se que você tenha seu banco de dados normalizado no mínimo na terceira forma normal. Assegure-se que suas chaves primárias são independentes de qualquer objeto de negócio que você esteja armazenando e, por razões de performance, use um Integer sempre que possível (Integers são 32 bits e ordenados mais rapidamente pela maioria dos algoritmos se comparado com campos Char e Varchar), a menos que você não possa fazer isto por uma razão específica (tal quando você precisa de um identificador único para replicação ou quando você está usando um banco de dados relacional para armazenar objetos). Chaves Primárias ---------------- Se você definir uma chave primária composta, mais que um índice é criado (um para cada coluna que compõe a chave). Como o otimizador de consultas usará os múltiplos índices para resolver a consulta, isto pode causar um gargalo para o otimizador, já que os múltiplos índices usados pelo otimizador são iguais aos campos da consulta. Chaves Estrangeiras ------------------- Chaves estrangeiras são essencialmente restrições de integridade referencial. O problema com chaves estrangeiras é que elas criarão um índice na respectiva tabela para facilitar a restrição. Normalmente isto não é um problema; contudo, se você tem uma restrição de chave estrangeira em colunas que tendem a não ter valores únicos, então você tem um índice bastante pobre. Se o otimizador de consultas utilizar um desses índices, isto causará um gargalo devido à pobreza dos índices. Nestes casos, remover os índices pode melhorar a performance das consultas em 100¬. Então tenha cuidado quando você definir suas chaves estrangeiras. Utilize Índices em Colunas de Ligadas (por operações de Join) ------------------------------------------------------------- Um índice é uma estrutura de dados de árvore balanceada que fornece uma melhora na velocidade de ordenação para um banco de dados. Índices do Intebase são de direções exatas (ascendente ou descendente) então, se você realiza uma busca de trás para frente nos dados de uma tabela, você deve definir um índice descendente. Índices trabalham melhor com dados que apresentam alguma exclusividade sobre ele. O otimizador de consultas do Interbase usará índices para acelerar as consultas. Índices na verdade podem ser prejudiciais à performance se criados em colunas que têm poucos valores únicos. Índices deixam lentas as inserções de dados em uma tabela, já que eles precisam ser recalculados a cada inclusão. Se você for fazer um grande número de inserções em uma tabela você pode considerar a desativação temporária de índices para minimizar o impacto de performance (ALTER INDEX name INACTIVE) e sua posterior reativação após as inclusões (ALTER INDEX name ACTIVE). Para determinar a eficiência de um índice, rode a seguinte instrução SQL: Select RDB$INDEX_NAME, RDB$STATISTICS from RDB$INDICES O valor RDB$STATISTICS mostra a eficiência do índice. Quanto mais baixo o valor, melhor o índice, com o valor 1 indicando um índice muito pobre. Como regra geral, você deve definir apenas uns poucos índices por tabela (o otimizador de consultas usará múltiplos índices para referenciar os mesmos campos conforme exigido pela consulta, portanto muitos índices podem degradar a performance). SQL --- Certas instruções SQL são mais lentas que outras. Geralmente, evite o uso de funções como ´CONTAINING´, ´LIKE´, ´´, ´COUNT´ e ´UPPER´ pois elas não usarão índices durante sua operação, tornando-as mais lentas que outros comandos. O livro ´SQL Performance Tuning´ de Peter Gulutzan e Trudy Pelzer cobre em detalhes como melhorar a eficiência de suas instruções SQL sem particularizar aspectos proprietários. Eu recomendaria este livro a qualquer um que esteja envolvido com o desenvolvimento em banco dados. Subconsultas Correlacionadas ---------------------------- Uma subconsulta correlacionada é uma subconsulta onde as condições da subconsulta são diferentes para cada linha na consulta principal. Por isto, as subconsultas precisam ser executadas várias vezes (uma para cada linha da consulta pai). Em alguns casos, uma junção pode substituir uma subconsulta correlacionada e resultará em um tempo de execução total menor para a mesma consulta. Joins Externos -------------- Outer joins são a realidade da programação em banco de dados. Left outer join tem a tendência de ser mais lento e um índice será apenas utilizado para a resolução do primeiro outer join na consulta. Onde possível, reduza a necessidade de left outer joins. Isto pode ser feito: - Projetando suas tabelas de forma a não serem necessários - Usando subconsultas (isto pode ser mais rápido que a solução left outer joins) - Usando um procedimento armazenado com select para aumentar a velocidade. Procedimentos Armazenados (Stored Procedures) --------------------------------------------- Quando criar um procedimento armazenado que contém laços aninhados assegure-se que o laço mais externo retorna o menor número possível de registros. Se possível, estruture seu procedimento armazenado de forma que os laços mais internos sejam sempre os mais rápidos já que são esses blocos os mais repetidos ao longo do processamento da rotina. Não Utilize Colunas Char e Varchar Longas ----------------------------------------- Antes do Interbase 7.0, Varchar´s and Char´s eram preenchidos ao tamanho do campo quando retornado ao cliente. Se você apenas preencher parte de um varchar grande ou um campo char e então retornar os resultados ao cliente, uma grande quantidade de tráfego de rede é gerado, degradando a performance de sua aplicação e da rede. Se possível, não use campos Varchar ou Char longos e, se possível, use BLOBs. Um Blob também tem a vantagem de ser armazenado em sua própria página no banco de dados e assim reduz a chance de qualquer bloqueio. Alternativamente, faça o upgrade para a versão 7.0 do Interbase. Colunas BLOB ------------ Um BLOB (Binary Large OBject) é um tipo e dado que suporta grandes objetos. Um Blob é definido com um tamanho de segmento e, no Interbase, este default é 80 bytes. Se um campo Blob é definido com um tamanho de segmento igual ao tamanho da página do banco de dados, então consultas a campos Blob tornam-se extremamente rápidas, pois apenas uma página precisa ser resgatada para retornar os dados. Sob estas situações, o Interbase não é um gargalo para a transferência de dados. Outros sistemas, como sistema de hardware, rede, etc, normalmente deixam baixa a taxa de transferência de dados. Utilize o Modelo Cliente-Servidor --------------------------------- Interbase fornece várias características que permitem que os processamentos sejam realizados no servidor (que possui geralmente maior capacidade de processamento que uma máquina cliente e também permite a redução do tráfego na rede). Triggers (gatilhos), UDFs e procedimentos armazenados são adequadamente detalhados no ´Guia do Programador´ e no ´Guia de definição de dados´ sem serem detalhados aqui. Plano de Consulta ----------------- Interbase usa um otimizador baseado em custo para otimizar a execução de instruções SQL. Na maioria dos casos, o otimizador faz um trabalho muito bom. Sob certas circunstâncias, o otimizador não seleciona o melhor plano para performance. Esteja informado que se você especificar seu próprio plano de consulta, o otimizador não analisará seu plano para assegurar que ele está correto. Detalhes de quando e como ajustar um plano de consulta do Interbase podem ser encontrados nos seguintes sites: * Specifying Query Access Plans in the Interbase Optimizer on the documentation page http://www.ibphoenix.com * Managing your Interbase Server by Paul McGee http://www.mers.com RDB$DB_KEY ---------- A rdb$db_key é um identificador de registro de baixo nível, mais rápido que chaves primárias para resgatar registros. Rdb$db_key´s são apenas válidos para a vida da transação corrente e não podem ser pensados como identificadores de registro imutáveis. É ainda possível utilizar rdb$db_keys para melhorar a performance de rotinas SQL em um banco de dados Interbase. A desvantagem é que este ganho de performance é específico do Interbase. Para mais detalhes em como utilizar rdb$db_key, por favor consulte os documentos localizados no seguinte website: http://www.cvalde.com/ibdocumentation Guia para o Servidor ==================== Utilize um Servidor Dedicado ---------------------------- Um servidor dedicado fornece a melhor performance para um banco de dados cliente-servidor. O custo de uma performance inadequada é muito maior que o custo da compra de um servidor dedicado. Performances baixas refletirão em você como desenvolvedor e normalmente resultarão em perda de tempo identificando e corrigindo problemas. Não leva muito tempo para você justificar os custos de um servidor dedicado. Utilize Linux ou Unix como SO do Servidor ----------------------------------------- Servidores Linux ou Unix têm melhor utilização de memória e de memória virtual, modelos de priorização de multi-processador mais eficientes e, frequentemente, requerem menos recursos de CPU e de memória que outros sistemas operacionais. Servidores Linux demonstram impressionantes tempos de atividade quando comparados a suas contrapartes Windows. Linux também não parece ser atormentado por processos misteriosos que degradam performance e que desaparecem logo que você loga no servidor para examinar o problema. Servidores Linux ou Unix podem ser integrados a redes Windows com SAMBA, fornecendo um ambiente homogêneo na perspectiva das estações cliente. Se Tiver que Usar o Windows --------------------------- Verifique a configuração do seu servidor Windows para ver se está configurado para fornecer os recursos máximos de compartilhamento ou para aplicações de segundo plano. Como estas opções estão localizadas em diferentes áreas em diferentes máquinas Windows, verifique sua documentação do Windows. Estes ajustes podem ter um grande impacto na performance do Interbase. Utilize Máquinas Mono-Processadas com InterBase ----------------------------------------------- Se você está usando uma versão do Interbase sob o Windows NT antes da versão 7.0, então não use um servidor com multi-processador na plataforma Windows. Se você fizer isto, o processo do servidor Interbase saltará de processador para processador causando degradação na performance do seu servidor. Se você quer usar Interbase (antes da versão 7.0) em um sistema com multi-processadores, então use uma ferramenta para amarrar o Intebase a um processador (há algumas delas disponíveis, inclusive uma da Microsoft). Contudo você deve ainda estar ciente que, como alguns dos sistemas operacionais Windows NT mais antigos não têm implementados um modelo adequado de suporte a SMP, o ganho de performance pode não ser tanto quanto o esperado. Sistemas Linux têm suporte a SMP adequado. Utilize um Disco Rígido Dedicado -------------------------------- Se você tem um banco de dados armazenado no mesmo drive que as pagefiles do servidor, a elevação das operações de I/O das operações de memória virtual do servidor impactará na performance de sua aplicação. Aloque sempre seu banco de dados em um drive separado. Se você tem dinheiro para isto, eu recomendaria que seu sistema operacional fosse para um drive, seu banco de dados para outro e o arquivo de swap para outro drive. E/S de Disco Rápida ------------------- Operações de I/O em disco são frequentemente um gargalo para performance do banco de dados. Drives IDE frequentemente usam algum recurso de CPU. Se você puder, coloque sistemas SCSI mais rápidos. Ser mesquinho nesta área custará muito a você em termos de degradação da performance. Sistemas RAID também oferecem melhor performance que sistemas de disco único. Um apropriado array de drives SCSI é a melhor solução. Utilize um IP Estático no Servidor ---------------------------------- Um IP estático no servidor significa que o endereço IP do servidor pode ser encontrado mais rápido do que se for usado um serviço de tradução de nomes de endereço. Este IP deveria ser armazenado no Host file do servidor e no Host files das máquinas cliente. Utilize TCP/IP como Protocolo de Rede ------------------------------------- TCP/IP é um protocolo baseado em conexão (pacotes são roteados para o receptor pretendido ao invés de ir para todas as máquinas) o qual gera menos tráfico de rede que protocolos sem conexão como NetBEUI and IPX/SPX. TCP/IP é também mais rápido que estes protocolos e tem a vantagem de estar disponível em uma grande variedade de plataformas. Sempre que possível, TCP/IP deveria ser usado para comunicar-se com o Interbase por suas vantagens de velocidade. Para melhorar a performance além disto não é aconselhável instalar múltiplos protocolos na rede pois isto aumenta o ´barulho´ na rede. Se isto for inevitável, assegure-se que o protocolo de rede que você usa terá maior prioridade através da rede. Não Utilize Proteção de Tela ---------------------------- Protetores de tela, particularmente os tipos 3GL podem estar sobrecarregando o processador e degradarão visivelmente o desempenho do sistema. Na maioria dos casos os protetores de tela não são necessários pois os monitores modernos são projetados de modo que o risco de queimar a tela seja insignificante pois possuem sistema de proteção de energia e se desligarão após certo período de tempo. Se você não tiver um monitor com sistema de proteção de energia somente desligue-o- você estará gastando menos energia e diminuindo o aquecimento da sua sala. Se você tiver que usar um protetor de tela então use uma tela em branco ou marquee (ajuste a velocidade do texto para uma taxa lenta para evitar a utilização excessiva da CPU) pois estes usam menos quantidade de recursos do sistema. Logins de Console ----------------- Muitas pessoas tendem a usar Windows NT/2000 pois estão mais familiarizadas com o sistema operacional Windows. Se você realmente usa Windows NT, então não faça login desnecessariamente ou fique logado. Além de ser uma questão de segurança, deixar o servidor logado permite que processos rodem em segundo plano, o que pode degradar a performance do servidor. Até mesmo processos em segundo plano podem usar de 20-30¬ dos recursos do servidor. Há várias ferramentas que permitem a você manter seu servidor Interbase sem a necessidade de ter o servidor continuamente logado. Utilize a Mesma Versão do Servidor no Cliente --------------------------------------------- Se você tem uma versão do Cliente do Interbase ultrapassada na sua máquina cliente, compare com a versão instalada no servidor. Você pode estar sofrendo com um problema de performance. Testes com Interbase 5.1 e 5.6 podem demonstrar uma performance diferente em pouco mais que 50¬ por usar uma instalação de cliente ultrapassada. Também, características mais novas podem não estarem disponíveis se você não está usando a mesma versão de cliente e servidor e erros de programa podem resultar (em alguns casos isto pode causar um crash no seu servidor Interbase e possivelmente corromper seu banco de dados). Vencendo Restrições de E/S de Disco ----------------------------------- É possível reduzir o problema de operações de E/S em discos no Interbase. Depois de ter realizado o backup e o restore, crie uma tabela temporária no banco de dados (usando campos Blob ou colunas Varchar grandes). Preencha esta tabela com uma grande quantidade de dados. Então apague (drop) a tabela temporária e faça o sweep do banco de dados. Isto significa que o Interbase irá aproveitar o espaço dentro do banco de dados durante operações e não pedirá para ao SO espaço em disco até que o espaço vazio dentro do banco de dados tenha sido aproveitado. Isto aumenta a velocidade de operações de gravação para o banco de dados na medida que E/S de disco não é essencialmente um fator de limitação. Proteção de Arquivos no Windows ------------------------------- Algumas versões do Windows (Windows XP) têm implementado mecanismos de proteção a arquivos com extensão.GDB (Banco de dados Interbase). Se você está usando Sistema Operacional Windows mais recente que Windows 2000, você pode experimentar de-activating Windows File Protection ou renomear seu banco de dados para uma extensão diferente (Para Banco de dados Interbase superior a 7.0 ou FireBird 1.5). Os cínicos entre nós podem querer saber se a Microsoft fez isto para reduzir a performance do Interbase em comparação ao seu próprio banco de dados, o SQL Server...

[b:3c75ba2f94]Guia de Performance Interbase (II)[/b:3c75ba2f94] Por Peter Mc Leod Tradução: Demian Lessa Configuração do Interbase ========================= Backups e Restaurações Regulares -------------------------------- Seu banco de dados é uma fonte de vantagem competitiva para seus clientes por causa da informação que contém. Realizar backups regulares é essencial para garantir a integridade dos dados de seus clientes. Restaurações são tão importantes já que otimizam o banco ao: - reconstruir índices, - eliminar versões obsoletas de registros (coleta de lixo), - desfragmentar páginas do banco, - reescrever as tabelas de forma contígua e - recalcular estatísticas do banco. Uma boa ferramenta para realizar backups e restaurações é o IBBackup que está disponível a partir de www.ibphoenix.com Nota: Aconselha-se que antes de restaurar seu banco de dados, você faça uma cópia do original e então proceda com a restauração. Isso se deve ao fato de que uma restauração realiza verificações de integridade no banco- uma atividade intensa em processamento. Como resultado, pode ser que um backup apresente problemas e não possa ser restaurado. A idéia do backup é conferir segurança sem impacto de performance. Classe de Prioridade Interbase ------------------------------ A Classe de Prioridade Interbase deve ser definida como alta (versão SuperServer no Windows) para assegurar que o Interbase pode solicitar mais recursos do sistema. Isso pode ser feito através do IBConsole na versão Windows. Ou editando o arquivo ibconfig e definindo a propriedade SERVER_PRIORITY_CLASS como 2 (remova o marcador de comentário ´#´). Desligue Async Writes --------------------- No Windows NT, o Interbase está configurado por padrão para executar escritas forçadas. Isso significa que as operações de escrita para o Interbase vão direto ao banco e não passam pelo sistema de cache do sistema operacional, normalmente lento. No Linux, o inverso ocorre. Isso pode resultar em diferenças de performance de mais de 300¬ para algumas operações. O problema é que se você desliga Async Writes no Windows, e o sistema operacional cai enquanto o Interbase escreve em disco, você corre o risco de perder dados e corromper seu banco. Como Linux é naturalmente mais estável esse não é um risco tão grande. Se você deseja desligar Async Writes tenha certeza de manter seus backups em dia e confirme que seu sistema de UPS no servidor está funcionando: GFIX -WRITE ASYNC/SYNC MYDATABASE.GDB Desligue a Coleta de Lixo ------------------------- Por padrão, o Interbase realiza uma varredura do banco para coletar o lixo de registros velhos, quando eles se acumulam. Infelizmente, isso pode causar sérios efeitos na performance do processo cliente que fez esse limite ser atingido. Para desabilitar a colta de lixo automática, você deve emitir o seguinte comando a partir do Gfix: gfix -h 0 Nota: Backups e restaurações regulares realizarão a coleta de lixo no banco. Essa é outra razão pela qual os backups e restaurações devem ser realizadas na máxima freqüência permitida. Posições Hash de Bloqueio ------------------------- O parâmetro Lock Hash Slots (Posições Hash de Bloqueio) é utilizado para determinar o tamanho da tabela de hash usada para encontrar os bloqueios em um objeto particular do banco (exceto nos sistemas VAX/VMS). O número deve ser primo para facilitar o algoritmo a gerar uma boa distribuição. Normalmente a primeira indicação de problema com esse parâmetro é a redução de performance do servidor (com vários usuários e um cache de páginas grande). Para determinar se o problema está na tabela, produza uma saída impressa da tabela (enquanto o sistema estiver em uso) e examine o comprimento médio do hash. Se for maior que 10 você está com problemas. Para calcular um novo valor para o Lock Hash Slots multiplique o comprimento médio pela quantidade atual de posições e divida o resultado por nove. Ajuste para maior para garantir que o número seja primo, mas que fique entre 101 e 2048 (os limites do parâmetro). Para alterar o parâmetro edite o arquivo ibconfig e mude o valor (remova o marcador de comentário ´#´). Eu normalmente uso LOCK_HASH_SLOTS com valor 503 para a maioria das instalações Interbase. Se você realizar essa operação na versão Super Server, você deve aumentar o tamanho da tabela de bloqueio também. Tamano de Página do Banco ------------------------- O tamano da página do banco determina a quantidade de dados que pode ser recuperada com um acesso lógico ao banco. O padrão para o Interbase é 1Kb, com valores permitidos de 2Kb, 4Kb e 8Kb. Para bancos pequenos, (menores que 4GB), defina o tamanho da página do banco para 4096 bytes (4KB); para bancos grandes, esse valor deve ser estabelecido em 8192 bytes (8K). Testes de performance em bancos de dados indicam que uma mudança no tamanho de página de 1KB para 4KB pode aumentar a performance em até 20¬. Ao utilizar páginas de 4KB para a maioria dos bancos, as operações de E/S do banco combinam com seus tamanhos de página com as do sistema operacional, resultando em maior eficiência e performance. Outras vantagens de páginas maiores incluem: · Menor fragmentação de registros e maior quantidade de registros por página · Menor quantidade de páginas retornadas por consulta (já que os registros são armazenados de forma mais contígua) · Índices em Árvore-B são mais rasos · E/S é mais contígua Os tamanhos de página indicados acima são diretrizes; recomenda-se que testes sejam realzados para a determinação do tamanho de página ótimo aplicável a cada sistema. Para que a alteração do tamanho de página do banco entre em funcionamento, será preciso realizar um backup e uma restauração do banco. Conjunto de Trabalho -------------------- Os parâmetros de configuração do conjunto de trabalho só são aplicáveis ao Interbase rodando sobre o Windows (arquitetura Super Server). Essas configurações determinam quanta memória RAM fica dedicada ao processo do Interbase. O conjunto de trabalho mínimo define a quantidade mínima de RAM física que é garantida ao processo do Interbase. O conjunto de trabalho máximo define a quantidade de memória a partir da qual o Interbase começará a usar o cache do sistema. Eu recomendo que o conjunto de trabalho mínimo seja determinado pelo valor de alocação das páginas de cache do banco somado a 3 MB. Deixando o conjunto de trabalho máximo em zero irá permitir que o próprio sistema determine o ponto no qual o Interbase deve ser transferido para disco. O conjunto de trabalho máximo deve ser sempre maior (ou zero) que o cache do banco ou o sistema irá paginar todas as operações contiuamente para disco. Cache do Banco -------------- O cache do banco de dados é um cache da quantidade de páginas do banco que serão mantidas no cache RAM do servidor. Alguma experimentação na definição do cache do banco (usando o ibconfig) a valores entre 256 e 10.000 produzem performances crescentes até um determinado ponto. Após esse ponto, performance reduzida é percebida. É uma boa idéia definir o cache de seu banco através do GFIX com o comando a seguir: Gfix -buffers 10000 -user sysdba -password masterkey mydatabase.gdb Se você tem um banco de dados pequeno, você deve utilizar estatísticas para determinar quantas páginas seu banco possui. Você não deve definir o cache para um valor maior que a quantidade de páginas do seu banco já que uma página do disco ocupará apenas uma página do cache. Considerações de Desenvolvimento ================================ Sempre Trabalhe com a Menor Quantidade de Dados Possível -------------------------------------------------------- Tráfego de rede é um fator preponderante na percepção da performance de sua aplicação. Se você possui 100.000 registros e você realiza algo como ´SELECT * FROM myTable´ você estará descarregando todos os registros. Utilizar filtros para retornar apenas um subconjunto dos dados reduz a quantidade de registros. Se possível, evite o uso de visões tabulares para conjuntos de dados grandes. Use o SQLMonitor (ou equivalente) para avaliar seus comandos SQL e verificar o que DE FATO ocorre enquanto sua aplicação roda. Não Mantenha Transações Abertas Mais Tempo que o Necessário ----------------------------------------------------------- Manter uma transação aberta pode travar registros em um banco. Manter transações abertas por períodos longos de tempo também irá aumentar a quantidade de memória que o Interbase requer para guardar o estado dessas transações. Ao invés de iniciar uma transação logo que a tela de entrada de dados é aberta e só confirmá-la quando o usuário pressionar o botão Salvar, é melhor manter uma cópia dos dados, iniciar uma transação e confirmá-la quando o usuário pressionar o botão Salvar. Um número de técnicas facilitam essa abordagem como, por exemplo, ClientDatasets. Essas técnicas apresentam inúmeras vantagens: · Reduzem o tráfego da rede · Reduzem o risco de bloqueios do banco · Reduzem o tempo de vida das transações · Reduzem a quantidade de memória necessária para o Interbase manter essas transações Sistemas Grandes, Muito Tráfego, Cache das Tabelas de Busca ----------------------------------------------------------- Se você possui dados que não mudam (como estados ou países), então você possui a oportunidade de disponibilizar esses dados em cache através de um ClientDataset na máquina do cliente (ao invés de recuperar os detalhes do servidor); você pode então simular uma ligação no lado do cliente através de um campo calculado. Isso permite reduzir o número de buscas no banco, reduzindo o tráfego na rede. Programe Diretamente sobre a API do Interbase --------------------------------------------- Se velocidade é uma absoluta necessidade, então um programa escrito em C com SQL embutido terá preformance melhor que uma aplicação Interbase cliente passando por camadas de middleware (como BDE). Esse tipo de aplicação é programada diretamente sobre a API em GDS32.DLL, que produz o ganho de performance. Use uma Conexão Remota ---------------------- Quando desenvolver sua aplicação não use uma conexão local para conectar-se ao banco (c:\path\mydatabase.gdb), já que esse tipo de conexão usa arquivos mapeados em memória para comunicação com o banco. Em algumas versões do Interbase o uso simultâneo de conexões locais e remotas pode causar a corrupção física do banco de dados. Use uma conexão remota sempre, já que essa modalidade de conexão oferecerá uma melhor indicação da real performance do seu sistema (servername:c:\path\mydatabase.gdb) e permitirá a identificação de problemas mais cedo. Melhor ainda, desenvolva sua aplicação conectando-se a um banco de dados numa máquina em outro ponto da rede. Alimente e Teste seu Sistema Durante o Desenvolvimento ------------------------------------------------------ Desenvolvedores normalmente utilizam um sistema limitado para testes na máquina de desenvolvimento. A desvantagem dessa abordagem é que a recuperação de alguns poucos registros (ou mesmo algumas centenas) no ambiente local será extremamente rápida. A realidade é que você deverá desenvolver um sistema cliente-servidor que irá executar em rede e que poderá ter alguns milhares ou mesmo milhões de transações. Para testar seu sistema, rode-o na rede e certifique-se de que o banco está alimentado devidamente (eu recomendaria alimentá-lo com aproximadamente 1/3 a mais de registros que o sistema de produção). Preferivelmente, realize seus testes no hardware mínimo e no ambiente de rede que você espera que seu sistema rode. Prepare e Parametrize suas Consultas ------------------------------------ Sempre que possível, escreva uma consulta que possa ser parametrizada e prepare a consulta antes de executá-la (ela só precisa ser preparada uma vez já que fica preparada até que você desprepare-a explicitamente ou altere o conteúdo da propriedade SQL). Consultas parametrizadas e preparadas são mais rápidas que consultas parametrizadas e não preparadas ou preparadas e não parametrizadas. Componentes VCL --------------- Um componente TQuery foi projetado para uso em aplicações cliente- servidor e deve ser utilizado sempre ao invés de TTable, que é para desenvolvimento de sistemas locais. Quanto utilizar TQuery, permita ao servidor lidar com atualizações, exclusões e conflitos definindo RequestLive como False. Não use Locate ou RecordCount já que esses métodos recuperam todos os registros. Use uma cláusula where para garantir que o servidor realiza a filtragem dos dados para você. Pense Sobre o que Está Fazendo ------------------------------ Quando projetar seu sistema lembre-se que só porque o Interbase permite que você faça algo não significa que é uma boa idéia. Todas as ações têm conseqüências. Pense no seu projeto, desenvolvimento e suas ramificações, na rede e nos clientes. Lembre-se que é possível que alguém tenha que dar manutenção nesse sistema. Algumas Coisas Serão Lentas --------------------------- Quando desenvolver um sistema se você tiver que realizar a mesma tarefa repeditamente, um milhão de vezes, digamos, será um processo lento não importa quão rápido sejam seus clientes e seu servidor. Se for esse o caso, verifique se sua filosofia de projeto permite que esse tipo de processamento seja retirado do sistema. Em alguns casos isso não será possível e você terá que empregar um mecanismo através do qual a tarefa é executada fora do expediente normal de uso do cliente. Use o Cliente ------------- Num sistema cliente-servidor, você não tem que enviar tudo de volta ao servidor para processamento. Você pode distribuir a carga realizando algum processamento no lado do cliente. Se você mantém detalhes de seus cálculos em cache, a vantagem é a redução no tráfego da rede, transações mais curtas e não ocupar o servidor com cada processamento. Um exemplo disso seria o cálculo do custo de cada item de um pedido de compra e o total da compra no cliente. Veja o que sua Aplicação Realmente Faz ao Invés de Pensar que ela Faz --------------------------------------------------------------------- Ferramentas como o SQL Monitor permitem que você tenha uma visão ampla da forma como sua aplicação solicita dados do Interbase. Essas ferramentas são valiosas ao permitir que você veja coisas como: · Conexão/Desconexão · Transações · Execução de Comandos · Operações sobre Comandos Váriso componentes da VCL se comportam de formas diferentes. Utilizando o SQL Monitor permite que você investigue o que está acontecendo por trás dos bastidores com esses componentes e também o que acontece quando você faz alterações no projeto de seu sistema. Outras ferramentas que devem estar no seu arsenal de desenvolvimento incluem: · Interbase Performance Monitor por Craig Stuntz (requer Interbase 7.0 ou superior) · Interbase Plan Analyser por Craig Stuntz · Sleuth QA Suite por TurboPower Software (permite ajustar a performance de aplicarivos Delphi/C++ Builder) Use Componentes para Acesso Nativo ---------------------------------- O BDE é agora um sistema obsoleto e não será mais suportado pela Borland. Componentes como IBX, FibPlus e IBObjects oferecem um ganho de performance de aproximadamente 40¬ em comparação com o BDE. Eles também oferecem acesso a mais recursos internos do Interbase. Para usar esses compontnetes, no entanto, amarra seu desenvolvimento ao Interbase. Se esse for um problema, então os componentes dbExpress oferecem a possibilidade de conectar-se ao Interbase e outros bancos ainda que mantendo uma boa performance (não tão boa quanto IBX etc, mas de certo muito melhor que o BDE). Buscando Registros ------------------ Soundex é um método de inexação, desenvolvido pelo departamento de recenseamento americano, para agrupar nomes que soam de forma semelhante. Como exemplo, realizar uma pesquisa de 300.000 registros para o nome ´smith´ pode levar 2,95s para completar enquanto que uma pesquisa usando soundex poderia retornar o resultado em 0,77s, exceto que o resultado incluiria, além do nome ´smith´, os nomes de todos que soam como ´smith´. Para uma boa introdução sobre a criação e utilização da função Soundex veja o artigo ´Implementing a Soundex Function´ por John Midwinter e encontrado em http://www.ibphoenix.com Outras Formas de Melhorar a Performance ======================================= Atualize o Interbase -------------------- Cada nova versão do Interbase (ou Firebird) traz melhorias que aumentam a performance do SGBD ou aumentam a flexibilidade do pragramador através de extensões de linguagem. A performance e a funcionalidade aumentadas permitem construir sistemas cliente-servidor melhores. Dada as recentes melhorias desses produtos, qualquer um usando uma vesão do Interbase anterior à versão 7.0 deve considerar uma atualização. Se essa não é uma opção, considere autalizar para a versão mais recente do Firebird. Bancos de Dados Somente-Leitura ------------------------------- Um banco normalmente reserva algum espaço livre em suas páginas (em torno de 25¬) para permitir a inclusão de novos registro. Num banco de dados onde o principal objetivo é a recuperação e visualização de dados, mais páginas precisam ser recuperadas para permitir a visualização. Para esses bancos somente-leitura, essas páginas podem ser preenchidas de modo que os dados estejam mais contíguos e menos páginas tenham que ser recuperadas. Utilize o seguinte comando GBAK: GBAK -C -USE_ALL_SPACE backup.gbk mydatabase.gdb