Buscar por:
10 passos para fazer o interbase "voar"

Código
Texto original : Bill Karwin

Adaptação e Tradução : Carlos H. Cantu

Inprise Conference, Agosto 1998

Design das Queries

Sub-queries co-relacionadas e joins

Subqueries são comandos SELECT que são incluídos como cláusulas ou expressões dentro de outros comandos. Geralmente são utilizados para gerar um valores ou um resultados que serão utilizados nas condições em um Query superior.

Uma Query correlacionada é uma em que as condições da subquery são diferentes para cada linha(registro) da Query pai, porque ela depende de valores que variam de linha para linha. O Interbase executa a subquery diversas vezes, uma para cada linha da Query pai. Avaliar cada linha tem um alto custo em performance em relação a Queries que não são correlacionadas. O InterBase optimiza Queries não-correlacionadas fora do loop, executa 1 vez, e utiliza o resultado como um dataset fixo.

Exemplo de uma query correlacionada:

SELECT *

FROM DEPARTMENT D

WHERE EXISTS

(SELECT *

FROM EMPLOYEE E

WHERE E.EMP_NO = D.MNGR_NO

AND E.JOB_COUNTRY = ‘England’)

O mesmo exemplo utilizando um JOIN:

SELECT D.*

FROM DEPARTMENT D JOIN EMPLOYEE E ON D.MNGR_NO = E.EMP_NO

WHERE E.JOB_COUNTRY = ‘England’

PLANo de execução de uma Query

O PLANo descreve o meio que o optimizador do IB escolheu para executar a Query. Para alguns tipos de Query, o optimizador pode não ter escolhido o plano mais adequado (eficiente). Uma pessoa pode analizar PLANos alternativos e especificar manualmente o plano à ser utilizado em uma Query, passando por cima da análise do Optimizador. O resultado pode ser um ganho muito grande de eficiência para alguns tipos de Query. Em casos dramáticos, o tempo de execução de uma Query foi reduzido de 15 minutos para 3 segundos !

Os elementos da definição de um plano são:

Atribuir os indíces

Combinar os indíces

Determinar a ordem do JOIN

Gerar os "rivers"

Estimativa de custo

Ordernar os "merges" 

Foi adicionado ao comando SELECT uma sintaxe para possibilitar que o usuário especifique o plano para uma Query. A sintaxe deve funcionar para SELECTs dentro de uma VIEW, STORED PROCEDURE ou TRIGGER.

Para maiores detalhes de como definir um plano, veja http://www.interbase.com/tech/docs/manage.html

Preparando as Queries e os Parâmetros da Query

O Interbase suporta Queries parametrizadas em DSQL, para casos onde um comando deve ser executado diversas vezes com diferentes valores. Por exemplo, preencher uma tabela com dados requer uma serie de comandos INSERT com os valores para cada registro inserido. Executar uma Query parametrizada tem um impacto benéfico na performance, pois o IB mantém a representação interna e a optimização da Query após prepara-la uma única vez.

Use Queries parametrizadas em DSQL no Delphi seguindo os seguintes passos :

Coloque um parâmetro no SQL utilizando a sintaxe ":PARAMETRO" no lugar de uma constante na Query. O Interbase não suporta parâmetros em nenhum outro lugar sem ser constantes. Tabelas e nomes das colunas não podem ser parametrizadas.

Prepare a Query. Use o método TQuery.Prepare. O Delphi automaticamente prepara uma Query quando a mesma é executa sem ter sido preparada anteriormente, mas nesse caso, após a execução, o Delphi automaticamente desprepara (Unprepare) a Query. Quando uma Query for executada diversas vezes, o programador deve manualmente preparar e despreparar a Query para evitar que a mesma fique sendo preparada/despreparada múltiplas vezes sem necessidade.

Especifique os parametros. No caso de uma TQuery, use PARAMS ou PARAMBYNAME para atribuir os valores para os parâmetros da Query.

Execute a Query. Queries contendo o comando SELECT devem ser executadas utilizando o método OPEN. Queries contendo comandos INSERT, UPDATE, e DELETE deve ser executadas pelo método ExecSQL. Esses métodos preparam a Query para ser executada caso isso ainda não tenha sido feito anteriormente. Para aumentar a performance, um aplicativo deve sempre PREPARAR uma Query antes dela ser executada pela primeira vez.

Repita os passos 3 e 4 quantas vezes quiser.

Desrepare a Query. 

Em casos reais, o uso de Queries parametrizadas aumentou a performance em 100%.

--------------------------------------------------------------------------------

Protocolo da Rede

O IB suporta os seguintes protocolos: NetBEUI quando conectar um servidor NT, IPX/SPX quando conectar um servidor NOVELL, e TCP/IP com qualquer servidor.

NetBEUI e IPX/SPX

Os protocolos NetBEUI e IPX/SPX são designados para serem utilizados em pequenas redes. Esse protocolos são normalmente utilizados para serviços de compartilhamento de arquivos. Esse protocolos enviam pacotes para toda a rede, aumentado o nível de "ruído" em uma LAN. O "ruído", do ponto de vista de qualquer terminal, pode ser definido com um tráfego de dados que não é designado para esse terminal. Em uma LAN com muitos terminais, usar os protocolos NETBEUI ou IPX/SPX pode afogar a rede e reduzir a banda livre para tráfego de dados. O uso desses protocolos é desencorajado.

TCP/IP

TCP/IP é um protocolo baseado em conexão, significando que os pacotes de dados são direcionados para um determinado terminal, reduzindo o tráfego da rede e nos terminais, disponibilizando muito mais banda livre, fazendo com que a performance não se degrade.

DNS

Cada terminal em uma rede TCP/IP tem designado um número IP que é utilizado para o direcionamento dos dados. O TCP/IP requer um meio para que os clientes traduzam os nomes dos terminais para seus respectivos números IP. Isso é feito em cada cliente, através do arquivos HOSTS/LMHOSTS, ou utilizando um servidor central chamado DNS. O DNS recebe o nome do host e devolve o número IP do mesmo para que o cliente se comunique diretamente com o terminal desejado.

Dependendo do volume de dados e da carga do servidor DNS, o processo de tradução de um nome para o IP pode levar alguns segundos, significando uma demora nas conexões da rede.

Então como posso aumentar a velocidade para a resolução dos nomes ? Ao invés de utilizar um DNS, use o arquivo HOSTS em cada terminal para determinar resolver os IPs. Procurar por uma linha dentro de um arquivo local é muito mais rápido do que esperar a resolução de um DNS remoto.

DHCP

Uma desvantagem do TCP/IP sobre os outros protocolos é que ele é mais díficil de ser gerenciado do que o NetBEUI ou o IPX/SPX. Todos os terminais de uma rede TCP/IP devem ter designados um único número IP. Isso acaba sendo uma árdua tarefa de configuração e administração.

O DHCP (Dynamic Host Configuration Protocol) pode facilitar essa tarefa. A estação pergunta ao servidor DHCP e o mesmo retorna um número de IP livre que pode ser utilizado pela estação. A estação usa esse IP pela duração da sua sessão na rede.

--------------------------------------------------------------------------------

Configuração das páginas do BD

Tamanho da Página (Page size)

O tamanho da página padrão utilizada pelo Interbase é de 1K. Há um aumento de performance de 25-30% se esse valor for alterado para 4K. Geralmente se fala que quanto maior a página, melhor é a performance, devido à razões que incluem :

Menos fragmentos de registros são dividos através das páginas

É comum que os registros ocupem mais de 1K, significando que em uma página de 1K, o registro é divido e armazenado em múltiplas páginas. Acessar esse registro faz com que o servidor tenha de ler várias páginas do BD. Se o tamanho da página for aumentado, o número de registros fragmentados diminui e podem ser gravados de modo mais contínuo.

Index B-trees são superficiais

Os índices são ponteiros em B-trees apontando para páginas de dados contendo porções dos valores indexados. Se a árvore B-tree for maior que 1 página, páginas adicionais são alocadas para a árvore de índice. Se as páginas de índices são maiores, algumas páginas adicionais são necesárias para armazenar os ponteiros. A árvore B-tree é facilmente alocada na memória pelo sistema de cache do BD, fazendo com que as procuras indexadas fiquem extremamente rápidas.

I/O é mais contínua

Normalmente registros sucessivos em uma tabela são lidos pela mesma Query. Isso é feito, por exemplo, durante um scan por uma tabela, ou por uma Query que retorna ou agrega todos os registros de uma tabela. O Interbase armazena os registros na primeira página livre do BD, não garantindo que registros sucessivos sejam armazenados perto um do outro. Um scan em uma tabela pode exigir que o servidor "pule" por todo o Banco de Dados acessando os registros, oque pode influir negativamente na performance.

Uma página do BD só pode armazenar registros de uma mesma tabela. Isso implica em que páginas maiores conterão mais dados de uma tabela e a leitura dessa página retornará dados mais relevantes.

Buffers maiores = mais memória de cache

O cache do BD é alocado em número de páginas ao invés de uma quantidade fixa de bytes. Então, definindo uma página maior implicará no aumento do cache/memória que conterá uma porção maior do BD. Estatisticamente, as chances dos dados serem encontrados em um cache grande é maior do que em um cache pequeno.

A maior parte dos sistemas operacionais executam leituras em baixo nível em blocos de 4096bytes.

Uma leitura de página é executado no nível do Sistema Operacional, lendo incrementos de 4096bytes independente do tamanho do BD. Definindo a página do BD em 4096 faz com que a leitura de uma página coincida com a leitura de baixo nível, garantindo uma melhor performance.

Voce pode mudar o tamanho padrão das páginas de um BD quando estiver criando ou restaurando um BD. A performance pode ser aumentada sem ter que mexer na arquitetura do BD. O tamanho das páginas é transparente para o cliente.

Embora 4K aparentemente seja o tamanho ideal para a maioria dos BDs, isso vai depender da estrutura de cada BD e do modo em que os aplicativos acessam esses dados, portanto, é aconselhável que voce faça alguns testes com outros valores para determinar o valor ideal para cada caso.

Compactando dados nas páginas para bancos de dados read-only

As páginas de dados armazenam múltiplas versões dos registros conforme os mesmos vão sendo atualizados. Quando um BD é restaurado, o GBAK preenche as páginas em até 80% do seu tamanho, deixando espaço para que novas versões dos registros possam ser armazenadas, com sorte, na mesma página que o registro original. No caso de um BD que é mais usado para leitura e nem tanto para inserção/atualização dos dados, esse espaço vago de 20% na página não é interessante. Nesse casos o melhor é restaurar os dados preenchendo 100% do espaço das páginas. Fazendo isso se reduzirá o número de registros fragmentados, bem como mais registros serão retornados durante a leitura de uma página. Para retaurar um BD com 100% de capacidade em cada página utilize a sintaxe :

GBAK -C -USE_ALL_SPACE backup_file.gbk database_file.gdb

--------------------------------------------------------------------------------

Transações

O Interbase exige que qualquer Query ou outra operação esteja associada com uma transação ativa. Isso é requerido pela arquitetura multi-geracional do IB. Sem uma transação, uma operação fica sem um contexto para manter um "snapshoot" do banco de dados. O WISQL e a BDE tem procedimentos automaticos que cuidam das transações durante as operações, mas é mais eficiente iniciar e terminar as transações manualmente.

No IB, um "snapshot" é gerado criando-se uma cópia do estado de todas as outras transações no BD. Esse "snapshot" é estático durante essa transação, o que significa que nenhum dado inserido ou alterado após o snapshot ter sido criado é visível a qualquer operação que se utiliza desse snapshot. Esse é o modo de isolamento conhecido como repeatable read. Assim se garante que 2 queries identicas executadas em diferentes horários sempre retornem o mesmo resultado, independente dos dados estarem sendo atualizados por outros clientes.

Iniciar uma transação e fazer um "snapshot" da estrutura de dados para a nova transação implica em algum tempo gasto. Esse tempo gasto é maior quando se utiliza um método de gerenciamento automático de transações, pois nele uma transação é iniciada e terminada para cada operação executada no BD.

Outro modo de isolamento (o padrão para a BDE) é chamado de read commited. Nesse modo, o "snapshot" é atualizado sempre que o estado de qualquer transação é alterado. Isso permite que as operações executadas dentro da transação atual "enxerguem" as alterações postadas após o snapshot ter sido criado. O processo de atualização do snapshot também consome algum tempo, por isso é aconselhável sempre utilizar o modo repeatable read no IB. Para isso, configure os flags no drive do Interbase na BDE para 512 ou 4608.

--------------------------------------------------------------------------------

Índices

Os índices podem aumentar dramaticamente a performance de um SELECT. Quanto mais registros houver em uma tabela, maior o benefício de um índice. Analizando corretamente seu banco de dados e definindo índices adequados sempre implicará em ganho de performance.

Um índice dentro do IB é uma estrutura de dados dentro do arquivo do BD que disponibiliza um meio rápido de acesso à valores específicos dentro de uma tabela. As queries automaticamente fazem uso apropriado dos índices graças ao optimizador do IB que analiza as tabelas e campos utilizados na query e determina quais os índices que agilizarão a procura, ordenação e as operações de join.

Os índices implicam em um pequeno "custo" para manter a estrutura da árqvore B-tree durante as operações de inserção e atualização dos dados. Por esse motivo voce não deve criar índices deliberadamente. Não crie índices redundantes e não crie um índice para cada coluna em uma tabela ao invés de analizar o BD para saber quais índices são realmente necessários.

Os índices são atualmente prejudiciais para a performance quando criados em colunas que contenham poucos valores únicos. Um exemplo clássico é a coluna SEXO dentro de uma tabela; os únicos valores para essa coluna seria feminino, masculino e talvez indefinido. Manter um índice como esse tem um custo alto de performance, e uma pesquisa nessa coluna consumiria mais tempo assim do que sem o índice.

O que utiliza um índice:

Chaves primárias e secundárias

Chaves de ordenação, incluindo DISTINCT e GROUP BY

Critério de busca (WHERE) 

O que não utiliza um índice:

Critério de busca utilizando CONTAINING, LIKE, <>

Colunas usadas em funções de agregamento, como por ex. COUNT()

Outras expressões, como UPPER() 

Índices Direcionais

Os índices podem ser definidos como ascendentes e descendentes (ASCENDING ou DESCENDING). Para ordenar em ambas as direções, voce precisa de um índice de cada tipo. Isso é muito importante de voce costuma utilizar DBGrids no Delphi.

Ajustando os índices

A seletividade de um índice é o indicador da sua exclusividade. O optimizador usa a seletividade no seu algoritmo para decidir se deve ou não utilizar um índice dentro de um PLANo em uma query. Se a seletividade está atrasada e não representa adequadamente o estado de um índice, o optimizador podera usar ou não o índice de maneira inadequada. Isso geralmente não provoca uma perda de performance, a não ser que a seletividade esteja muito desatualizada. Para recalcular a seletividade de um índice use :

SET STATISTICS name;

Periodicamente, a estrutura da árqvore B-tree pode se tornar desbalanceada, ou pode conter valores na árvore que não existem mais no BD (isso não deve acontecer no IB 5.0 ou superior devido ao recurso de Index Garbage Collection). Voce deve periodicamente re-construir um índice :

ALTER INDEX name INACTIVE;

ALTER INDEX name ACTIVE;

--------------------------------------------------------------------------------

Cache do Banco de Dados

O processo IBSERVE.EXE rodando no servidor mantém um cache na memória com os dados e as páginas de índices utilizados recentemente. Como qualquer cache, o ganho de performance depende da repetição dos acessos aos mesmos dados. Nas versões SuperServer do IB (IB 4.2 e superiores), o cache é compartilhado com todos os clientes conectados ao BD.

Por default, o IB aloca memória suficiente para armazenar 256 páginas do BD. Se o tamanho da página está definido em 1K, então 256K de memória será usada pelo cache. Se o tamanho da página é de 4K, então 1MB de memória será usada. A API do Interbase possibilita uma maneira de qualquer cliente pedir ao servidor que o tamanho do cache seja aumentado. A partir do IB 5.0, voce pode setar uma propriedade em cada BD que especifique o tamanho do cache que deve ser usado quando houver uma conexão ao BD.

GFIX.EXE -BUFFERS 5000 DATABASE.GDB

O valor padrão de 256 foi utilizado para máquinas com pouquissíma memória, impedindo que o IB consumisse muita memória no sistema. Aumentar o tamanho do cache é benéfico para a performance. Nos servidores de hoje, onde há grande quantidade de memória disponível, é altamente recomendável que se aumente o tamanho do cache.

Não aumente o tamanho do cache em um valor muito alto, que faça com que o IBSERVER.EXE tenha que utilizar a memória virtual (SWAP) do servidor. Isso estaria anulando totalmente a vantagem de se usar um cache visto que o acesso ao disco (SWAP) é muito mais lento do que o acesso à memória.

Não aumente o tamanho do cache para um valor mais alto do que o número de páginas do BD (voce pode ver o número das páginas através do Server Manager na opção Database Statistics ou através do utilitário GSTAT.EXE). Qualquer página do disco ocupa apenas 1 página no cache e nunca é duplicada.

Um bloco de memória é alocado para cada cache por cada BD. Se um cliente se conecta à 2 BD diferentes no mesmo servidor, o processo IBSERVER.EXE manterá 2 áreas de memória separadas para cada cache.

Voce deve experimentar os valores do cache e analizar o ganho de performance para cada caso. Voce pode ganhar até 30% de performance com isso.

--------------------------------------------------------------------------------

Bufferização de I/O

O IB em plataformas Windows-Intel implementa um cache de gravação do tipo write-through como padrão. Cada operação de escrita no cache é imediatamente passada para o Sistema Operacional (que pode utilizar um cache de gravação ou não).

Em contraste, o modo de cache write-back armazena e atrasa a gravação dos dados para depois. Múltiplas operações de escrita para uma página do cache são executadas na memória para depois serem gravadas no disco, resultando em um melhor tempo de resposta para a maioria das operações de escrita. O modo write write back é muito mais eficiente do que o modo write-through.

O Interbase utiliza o modo write-back como default nas versões em UNIX, mas não na versão Wintel. O modo write-back pode ser configurado manualmente através do comando GFIX.EXE -WRITE ASYNC ou desativando a opção "Enable Forced Writes" na página "Database Properties" no Server Manager.

O benefício de se usar escrita assíncrona (write-back) é de mais ou menos 4 vezes mais performance, apesar de alguns usuarios reportarem um ganho de até 20x em aplicações que executam muitas operações de escrita (INSERT, UPDATE, DELETE).

O problema do write-back é que dados podem ser perdidos no caso do servidor sofrer uma queda de energia, ou se o IBSERVER.EXE travar ou for finalizado de maneira anormal. Isso não ocorre se o modo escolhido é o write-through. Se voce testou e verificou que o servidor não está suscetível à esses problemas, então é recomendável que voce utilize o modo write-back.

--------------------------------------------------------------------------------

Servidor Ativo

O Interbase oferece metadata ativa para permitir que o servidor de banco de dados seja centralizado :

Regras de negócios (Business rules )

Segurança

Integridade de dados

Menos tráfego na rede 

Características do InterBase para a metadata ativa 

Triggers

Stored Procedures

SELECT Procedures

Integridade Referencial em cascata (PRIMARY KEY e FOREIGN KEY)

Privilégios de SQL

Funções definidas pelo usuário

Exceções definidas pelo usuário

Eventos 

Veja http://www.interbase.com/tech/docs/trig_sp.html http://www.interbase.com/tech/docs/udfs.html para mais informações.

--------------------------------------------------------------------------------

Configuração da BDE

Mude os padrões da BDE através do BDE Administrator.

Driver flags

O valor recomendável para a opção DRIVER FLAGS é de 4608.

Setando 512 ao valor do DRIVER FLAGS na BDE, voce estará especificando que o modo de isolamento transacional utilizado será o "repeatable read", reduzindo assim o overhead que o modo de transações automáticas ocasiona. (veja #7: Transações).

Utilizando o valor 4096 na opção DRIVER FLAGS, voce estará setando a BDE para utilizar o modo "soft commit". Soft commits é um recurso do IB que permite o driver reter o cursor enquanto está executando as alterações. Soft commits aumenta a performance nas atualizações de grandes volumes de dados. Quando se usa hard commits, a BDE deve reler todos os registros de um dataset, mesmo após a mudança de um único registro. Isso não é tão problemático quando se está usando um banco de dados desktop, pois os dados são transferidos no centro de memória. Para um banco de dados C/S (como o InterBase), atualizar um dataset consome muita banda da rede e degrada a performance radicalmente. No modo soft commit, o cursor é mantido e não ocorre a re-leitura dos dados (refetch).

DRIVER FLAGS

 Tipo de Isolamento

 Tipo de Execução

0

 Read committed

 hard commit

512

 Repeatable read

 hard commit

4096

 Read committed

 soft commit

4608

 Repeatable read

 soft commit

Aviso: soft commits nunca são usados em transações explícitas iniciadas pelas aplicações BDE. Isso significa que se voce inicia e termina suas transações explicitamente, o driver flag para soft commit não é usado.

Modo SQL Passthru

O valor recomendado para essa propriedade é SHARED NOAUTOCOMMIT

SQLPASSTHRU MODE especifica como a BDE e comandos explícitos em SQL compartilham a mesma conexão. Na maioria dos casos, o modo SQLPASSTHRU MODE é configurado para SHARED AUTOCOMMIT. Se no entanto, voce deseja enviar ao servidor comandos de controle de transação, voce deve utilizar o SQL Explorer e setar o modo SQLPASSTHRU para NOT SHARED. Há casos reportados de ganhos de performance de até 10x utilizando essa setagem, no entando isso dependo do volume de dados.

Utilize controle de transação explícita e evite instruções de autocommitted. Utilize sim os comandos:

TDatabase.StartTransaction

TDatabase.Commit

SQL Query Mode

Configure para SERVER permitindo que o servidor SQL interprete e execute os comandos SQL, e não a BDE.

--------------------------------------------------------------------------------

Propriedades dos componentes VCL

TQuery

CachedUpdates = False

Permite ao servidor gerenciar as atualizações, deletações e conflitos

RequestLive = False

Há relatos de usuários do Delphi que setando essa opção para false previne que o VCL mantenha uma cópia dos dados no cliente, diminuindo o tráfego na rede.

Em uma configuração C/S, uma re-leitura ("fetch-all") é a "desgraça" da performance, pois ela provoca a re-leitura de toda uma dataset, sobrecarregando a rede. Aqui estão alguns casos onde uma TQuery provoca um fetch-all :

O método Locate; use somente em base de dados locais

A propriedade RecordCount; é interessante saber quantos registros há em um dataset, mas isso gera um fetch-all.

A propriedade Constraints; Deixe que o servidor se encarregue disso.

A propriedade Filter; use a cláusula WHERE para que o servidor selecione os dados.

Commit, quando os flags não são 4096, ou quando estiver usando controle de transações explícitas. 

TTable

A TTable é designada para o uso em tabelas de médio tamanho em base de dados locais. A TTable lê informações da metadata de uma tabela, e tenta manter um cache dos dados do dataset na memória. Essa cópia dos dados é atualizada quando voce executa um POST ou um ROLLBACK. Isso implica em uma grande sobrecarga na rede para a maioria dos banco de dados C/S, que tem tabelas muito maiores e que geralmente são acessados por toda a rede. Voce pode observar a atividade de uma TTABLE através do SQL monitor, que lhe mostrará todas as chamadas da TTABLE feitas para a BDE e para a API do Interbase.

Não use TTable para C/S, use TQuery

Apesar da TTable ser muito conveniente por suas características RAD e seu modelo abstrato, ela deve ser evitada com o Interbase. A TTable não foi designada para ser utilizada em aplicações client/server.

Alternatives para a BDE

IB Objects

IBX

Free IB Components

--------------------------------------------------------------------------------

Informações adicionais

Screen savers

Não utilize Screen Savers (Protetores de tela) no servidor ! Pode parecer que não mas eles consomem processamento e podem fazer grande diferença na performance do seu servidor, principalmente os baseados em Open GL ! Se voce for utilizar um screen saver, opte por aqueles que simplesmente deixam a tela preta ou colocam o monitor em stand-by.

Console logins

Não deixe o servidor logado em uma máquina Windows NT. Mesmo quando o desktop está em idle, ele pode estar utilizando até 30% do processamento só para manter a interface. Basicamente todas as tarefas relativas a manutenção do BD podem ser realizadas em qualquer estação de trabalho.

Fast I/O

Utilize um HD rápido. Algumas considerações:

Use SCSI; O uso da tecnologia SCSI diferente do que muitos pensam não tem um ganho de transferência muito superior a da EIDE

(PC Magazine, http://www.zdnet.com/pcmag/pclabs/report/r960702a.htm); mas as interfaces SCSI bus-mastering toma menos recursos da CPU

Use um controlador de disco com memória cache embutida

Disk striping (incluído em RAID níveis 0, 3, ou 5) ganha em acesso paralelo à multiplos discos; relatos de até 10x.

Pesquise a performance antes de comprar um HD 

Servidor Dedicado

Utilize sempre um servidor dedicado. Use máquinas separadas para servidor de impressão e arquivos.

Optimização do Windows NT

Jung Vu (jungv@knowledgeweb.com) escreveu:

"Configurando o Windows NT para "Optimized for Network Applications" (Painel de Controle -> Rede -> Servidor) aumenta e muito a performance do IB. O pico de consumo que pode ocorrer por alguns segundos deixará de acontecer."

Multiprocessadores

Muitos usuários tem reportado apenas um modesto ganho de performance com o uso do IB em sistemas com multiplos processadores. Apesar do IB ser certificado para funcionar com SMP, sua versão atual não implementa características de execução paralela (que está planejada para uma futura versão).

O gerenciador de locks do IB não está condificado em multi-tarefa, portanto os acessos aos dados tendem à ser serializados. Isso geralmente não é um fator limitante de performance, pois o gerenciamento de locks é uma operação de alto rendimento se comparado à I/O física.

Sistemas SMP podem trazer benefícios ao IB pensando que as CPUs adicionais podem se ocupar com outros serviços do servidor, como serviços de rede, desktop e outros processos. O tamanho do ganho de performance nesses casos depende da demanda de outros processos relacionados ao processo servidor IB. Baseado nos relatórios de alguns clientes, esse ganho é de 5% a 20%. Por outro lado, nosso suporte técnico prefere dizer que o SMP atualmente contribui para degradar a performance do IB quando utilizado no Windows NT.

Tamanho dos campos Blob

Um Blob é um tipo de dado sem limite definido de tamanho. Ele pode ter muitos MBs, um tamanho muito maior que qualquer banco de dados pode gerenciar em uma simples operação de I/O. Portanto, BLOBs são definidos como uma série de segmentos do mesmo tamanho, e a interface de I/O transfere 1 segmento de cada vez. O padrão do tamanho do segmento no IB é de 80bytes.

É aconselhável que se defina o segmento de um BLOB para o mesmo tamanho da página. Se ambos o segmento do BLOB e a página estão definidos em 4096, queries com vários blobs podem atingir a velocidade de transferência de 20MB/s. O Interbase deixa de ter qualquer fator de limitação de performance.

Prefira o UNIX/LINUX ao Windows NT

O UNIX e o Linux são sistemas operacionais mais indicados para servidores do que o Windows NT. Em escalabilidade, segurança, estabilidade e especialmente performance, o Unix/Linux contém tecnologia mais madurada e testada. Em todas essas áreas, o Linux/Unix mostrá a sua superioridade sobre os sistemas operacionais da Microsoft. Algumas das áreas onde a deficiência do NT resulta em performance inferior incluem :

o NT faz um uso pobre da memória (incluindo a virtual)

o NT tem um modelo de prioridade de multiprocessamento pobre

o NT tem bugs nos seus processos de scheduling nos hardwares SMP

o NT requer muito mais CPU e memória para atingir a mesma performance do Linux/Unix 

--------------------------------------------------------------------------------

Interbase-BR - Copyright (c) 2000 by Carlos H. Cantu 

willian luiz andrade