Guia de Performance Interbase / Firebird II

[size=24:e24be0007c][b:e24be0007c]Guia de Performance Interbase II[/b:e24be0007c] [/size:e24be0007c] Por Peter Mc Leod Tradução: Demian Lessa [b:e24be0007c][size=18:e24be0007c]Configuração do Interbase[/size:e24be0007c][/b:e24be0007c] [b:e24be0007c]Backups e Restaurações Regulares[/b:e24be0007c] 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. [b:e24be0007c]Classe de Prioridade Interbase[/b:e24be0007c] 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 ´#´). [b:e24be0007c]Desligue Async Writes[/b:e24be0007c] 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 [b:e24be0007c]Desligue a Coleta de Lixo[/b:e24be0007c] 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. [b:e24be0007c]Posições Hash de Bloqueio[/b:e24be0007c] 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. [b:e24be0007c]Tamano de Página do Banco[/b:e24be0007c] 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. [b:e24be0007c]Conjunto de Trabalho[/b:e24be0007c] 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. [b:e24be0007c]Cache do Banco[/b:e24be0007c] 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. [b:e24be0007c][size=18:e24be0007c]Considerações de Desenvolvimento[/size:e24be0007c][/b:e24be0007c] [b:e24be0007c]Sempre Trabalhe com a Menor Quantidade de Dados Possível[/b:e24be0007c] 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. [b:e24be0007c]Não Mantenha Transações Abertas Mais Tempo que o Necessário[/b:e24be0007c] 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 [b:e24be0007c]Sistemas Grandes, Muito Tráfego, Cache das Tabelas de Busca[/b:e24be0007c] 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. [b:e24be0007c]Programe Diretamente sobre a API do Interbase[/b:e24be0007c] 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. [b:e24be0007c]Use uma Conexão Remota[/b:e24be0007c] 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. [b:e24be0007c]Alimente e Teste seu Sistema Durante o Desenvolvimento[/b:e24be0007c] 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. [b:e24be0007c]Prepare e Parametrize suas Consultas[/b:e24be0007c] 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. [b:e24be0007c]Componentes VCL[/b:e24be0007c] 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ê. [b:e24be0007c]Pense Sobre o que Está Fazendo[/b:e24be0007c] 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. [b:e24be0007c]Algumas Coisas Serão Lentas[/b:e24be0007c] 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. [b:e24be0007c]Use o Cliente[/b:e24be0007c] 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. [b:e24be0007c]Veja o que sua Aplicação Realmente Faz ao Invés de Pensar que ela Faz[/b:e24be0007c] 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ários 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) [b:e24be0007c]Use Componentes para Acesso Nativo[/b:e24be0007c] 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). [b:e24be0007c]Buscando Registros[/b:e24be0007c] 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 [b:e24be0007c][size=18:e24be0007c]Outras Formas de Melhorar a Performance[/size:e24be0007c][/b:e24be0007c] [b:e24be0007c]Atualize o Interbase[/b:e24be0007c] 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. [b:e24be0007c]Bancos de Dados Somente-Leitura[/b:e24be0007c] 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