Dicas para melhorar a performance do servidor

Firebird
•Use índices corretamente
Defina índices para todas as colunas que vão ser usadas para join’s ou
ordenações. Os índices são estruturas de dados de árvores balanceadas
que fornecem um grande aumento na velocidade da procura dos valores
nas colunas em que os índices são definidos. Isto é especialmente útil
quando ordenamos por uma coluna em particular ou juntamos duas
tabelas por uma coluna que as duas têm em comum.
Lembre que um índice Firebird é específico para uma direção de
ordenação, ascendente ou descendente (ASCENDING x DESCENDING),
e a direção de um índice deve ser igual à direção escolhida quando se faz
a ordenação. Se você for usar as duas direções, ascendente ou
descendente, crie dois índices para as chaves de ordenação. As
inclusões e alterações usam índices para serem gravadas, o que pode
prejudicar a performance durante um INSERT ou UPDATE, mas alguns
custos impostos durante a entrada de dados podem resultar em um
grande ganho de performance mais tarde na pesquisa destes dados.
Para minimizar a perda de performance durante um INSERT, considere
em desabilitar os índices durante um grande volume de INSERTs. Isto irá
‘desligar’ os índices, tornando-os indisponíveis para ajudar a acelerar as
pesquisas, mas também não vão ser atualizados durante os INSERTs.
Então, reabilite-os depois de terminados os INSERTs, e os índices serão
atualizados e balanceados uma vez para todos os dados incluídos.
Periodicamente reconstrua os índices, desativando e ativando
novamente (ALTER INDEX nome INACTIVE; seguido de ALTER INDEX
nome ACTIVE;). Recalcule o índice seletivamente (SET STATISTICS
INDEX nome;) se uma mudança na tabela afeta a distribuição regular dos
valores e dados. Os índices também são reconstruídos do mesmo modo
durante o restore.

•Otimize as pesquisas
O Firebird irá analisar uma pesquisa (query) e o otimizador fará a
melhor estimativa de quais índices deverão ser empregados para acelerar
a pesquisa. Mas nenhum otimizador automático é infalível. Para queries
complexas que serão usadas freqüentemente, ou que serão aplicadas a
um número elevado de dados, construa a pesquisa cuidadosamente. Use
a opção SET PLAN da ferramenta ISQL para testar queries, ver sua
performance e ver qual PLAN o otimizador escolheu. No Interbase v4.0,
v4.1 e v4.2 existem alguns problemas conhecidos em tais queries usando
a sintaxe JOIN na linguagem ANSI SQL-92, que não são analisados e
otimizados corretamente. Evite esta sintaxe ou, se tiver que usá-la,
especifique seu próprio PLAN.
•Ajuste o cache do Firebird
O Firebird mantém seu próprio cache de páginas do banco de dados
correntemente em uso na RAM do servidor. O tamanho padrão do cache
na versão superserver (Windows) é 2048 páginas de banco de dados (isto
é compartilhado por todos os clientes conectados a um dado banco de
dados). Para um banco de dados com 1Kb de páginas, isto ainda é
somente 2048Kb. A maioria dos servidores tem muita memória, então
ponha em uso! Experimente ajustar o cache de 256 até 10.000 páginas.
Em algum ponto verá diminuir os retornos, mas alguma experimentação
irá revelar este ponto.

•Faça Backup / Restore

Existem vários benefícios em fazer periodicamente um backup/restore
de um banco de dados Firebird usando o utilitário GBAK:
-reconstruir índices;
-eliminar versões obsoletas de registros (‘garbage’);
-defragmentar páginas de dados;
-regravar tabelas de dados contiguamente; e
-fazer uma cópia dos dados!

•Use processamento Cliente-servidor

Usando funções externas (UDFs), Triggers, Stored Procedures e Select
Procedures fazem com que o banco de dados faça muito processamento
no servidor, que provavelmente é um computador muito mais potente que
a estação de trabalho. Esta técnica evita também tráfego de rede
desnecessário. Veja na documentação (‘Developers Guide’ e ‘Data
Definition Guide’) detalhes do uso de UDFs, triggers e stored procedures.

•Use o cache de disco do Sistema Operacional

A maioria dos sistemas operacionais oferece sistema de cache de
disco para leitura/gravação. Com isto os programas podem fazer suas
gravações na RAM do servidor, e o sistema operacional irá salvar este
conteúdo fisicamente no disco periodicamente. Fazendo sempre
pequenas gravações ou fazer de uma só vez numa operação maior pode
aumentar bastante a performance de leitura/gravação de dados.
Usar este sistema de cache de disco é algumas vezes chamado de
leitura/gravação assíncrona (asynchronous I/O) ou gravação em cache
(cached writes). Forçando a gravação direta dos dados no disco,
sobrepondo o sistema de cache, é chamado de leitura/gravação síncrona
(synchronous I/O) ou gravação forçada (forced writes). O sistema de
leitura/gravação assíncrona tem o benefício de aumentar a performance,
mas como a RAM é um sistema volátil de armazenamento, pode perder
dados se houver uma queda de energia ou uma falha no servidor ou
ainda uma reinicialização do servidor quando o cache ainda não tiver sido
descarregado no disco. A leitura/gravação síncrona garante que nada
será perdido por estar no cache, mas ler ou gravar diretamente no disco é
bem mais lento que fazê-lo na RAM.
O Firebird permite fazer a leitura/gravação assíncrona ou síncrona. O
comando GFIX –WRITE SYNC <meubanco>.GDB faz o banco de dados
usar a gravação forçada (forced writes), e o comando GFIX –WRITE
ASYNC <meubanco>.GDB faz o banco usar a gravação em cache
(cached writes).
A gravação em cache pode ganhar muito em performance no Firebird,
mas devem ser tomadas medidas de proteção contra perda de dados. Por
exemplo, usando espelhamento de disco para manter uma duplicação dos
dados. Usando também no-break e estabilizadores para garantir uma
energia estável e ininterrupta para o servidor. Com medidas como estas,
a leitura/gravação assíncrona pode trazer benefícios sem sacrificar a
segurança.

•Administre o protocolo de rede

O protocolo TCP/IP é muito mais rápido que o SPX ou NetBEUI.
Conectar sua rede usando TCP/IP resultará em uma melhor performance.
O serviço NetBEUI tem um prioridade baixa em servidores NT, mas
existe um meio no sistema operacional para aumentar a prioridade deste
serviço. Alguns usuários dizem ter aumentado a performance depois de
ter feito isto. Veja na documentação do Windows NT as instruções para
ajustar a prioridade dos serviços NetBEUI.
NOTA: A partir do Windows NT 4.0, a performance da implementação
do Microsoft NetBEUI foi aumentada. É agora pelo menos tão boa quanto
a implementação do Microsoft TCP/IP, entretanto, em uma rede ocupada,
o NetBEUI é ainda limitado por ser um protocolo independente de
conecção. Isto significa que cada host na rede deve checar cada pacote
para ver seu conteúdo. Com mais hosts transmitindo na rede, cada host
deve manipular uma crescente leitura de “números errados”.

•Escolha o sistema operacional

Sistemas operacionais basados no UNIX/Linux são sempre mais
rápidos em multiprocessamento que sistemas Windows em um mesmo
equipamento. Se velocidade é algo importante para você considere o uso
desta plataforma. Pense sempre em utilizar o Firebird como servidor
dedicado, que não funcione como servidor de arquivos, pois ele poderá
ficar sentado no “banco de trás” nas questões de prioridade de
processamento.
 No Windows NT o servidor é configurado para dar prioridade ao
compartilhamento de arquivos. Você pode modificar esta configuração no
servidor: Painel de Controle -> Rede -> Software de Rede. Modifique
para “balancear” ou “servidor de banco de dados”. Esta modificação irá
resultar em uma melhora dramática na performance do Firebird.
O uso de sistemas operacionais não específicos para us ode
Servidores como os Windows 9x, Me ou XP Home podem prejudicar sua
performance, além das fragilidades conhecidas.

•Considere a limpeza do lixo (garbage collection)

O Firebird tem por padrão a função de automaticamente limpar as
antigas versões dos registros quando estas se tornam muito numerosas.
O problema deste método é que se um processo cliente que for sem sorte
suficiente para iniciar uma transação que coincida com o início da limpeza
automática, vai ter que esperar o trabalho de limpeza. O processo cliente
atrasa enquanto o processo de limpeza é feito. Desabilite a limpeza
automática (automatic garbage collection), usando GFIX –h 0, em favor
da limpeza programada (scheduled database sweep), usando GFIX –s.
Isto irá eliminar a perda na performance do cliente.
Fazer um backup e restore efetivamente faz a mesma coisa do que
uma limpeza completa no banco de dados. O backup somente copia a
versão mais recente de cada registro, nunca copia versões anteriores,
assim, quando os dados são restaurados, existe somente uma versão de
cada registro. Existem também outros benefícios de fazer backup/restore,
descritos na seção própria deste artigo.
Falando em limpeza do lixo, muitos programadores não se dão conta
da necessidade de iniciar e terminar (START e COMMIT) suas transações
com o banco de dados. Abrir transações impede que a varredura
periódica complete a limpeza do lixo, e a performance irá sofrer
progressivamente com o tempo.

•Normalize seu banco de dados

Projete seu banco de dados com uma normalização adequada dos
dados. Registros que têm muitos grupos de campos repetidos são
maiores que deveriam ser, podem aumentar o custo de ordenação e
ainda podem causar a ocupação de mais páginas do que o necessário,
resultando em uma maior fragmentação de páginas e um banco de dados
enorme sem necessidade.

•Pense nas transações

Projete sua aplicação para que resolva o mais rápido possível as
transações depois de abertas. Freqüentemente os programadores de
aplicação abrem uma transação e apresentam uma tela de entrada de
dados para o usuário. Ao invés disso, pegue os dados com o usuário
antes, abra uma transação para dar o INSERT e então dê o COMMIT na
transação imediatamente. O propósito disto é diminuir o tempo de
duração das transações, que diminui a probabilidade de duas aplicações
concorrentes conflitarem em um bloqueio de registro. Isto também ajuda a
evitar muitos ROLLBACKs e tráfego de rede, já que a sua aplicação
decide quando submeter os dados ao banco ou descartá-los.

•Programe com a API do Firebird

Um programa escrito em C com SQL embutido responde melhor que
uma aplicação cliente Firebird escrita em Paradox, Delphi ou outra
ferramenta visual. A idéia é programar diretamente na API do Firebird ao
invés de adicionar camadas intermediárias com mais um protocolo de
rede sobre ele.

Artigo Original:
http://www.ibphoenix.com/main.nfs?a=ibphoenix
&l=;IBPHOENIX.PAGES;NAME='ibp_tip_perf'

Time da IBPhoenix http://www.ibphoenix.com

Tradução e adaptação: Comunidade Firebird de Língua Portuguesa

Visite a Comunidade em:

Magda R. De Carli
mc@via-rs.net http://www.comunidade-firebird.org
A Comunidade Firebird de Língua Portuguesa foi autorizada pelo Autor do Original para elaborar esta tradução.