UNIVERSIDADE ESTADUAL DE MONTES CLAROS

Centro de Ciências Exatas e Tecnológicas

Departamento de Ciências da Computação
Curso de Sistemas de Informação

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS

BANCOS DE DADOS
POSTGRESQL E FIREBIRD
NA PLATAFORMA WINDOWS 2000

MONTES CLAROS - MG
2007
 I

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS

BANCOS DE DADOS
POSTGRESQL E FIREBIRD
NA PLATAFORMA WINDOWS 2000

Projeto Orientado de Conclusão de Curso

apresentado ao Departamento de
Ciências da Computação da Universidade
Estadual de Montes Claros, como
requisito parcial para a conclusão do curso
de Sistemas de Informação, orientado
pelo professor Ms. João Batista Mendes.

MONTES CLAROS - MG
2007
 II

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS

BANCOS DE DADOS
POSTGRESQL E FIREBIRD
NA PLATAFORMA WINDOWS 2000

Aprovada em 19 de Junho de 2007.

_________________________________
Prof. Ms. JOÃO BATISTA MENDES
Orientador

_________________________________
Profª. CHRISTINE MARTINS DE MATOS
Avaliadora

_________________________________
Profª. SÔNIA BEATRIZ DE OLIVEIRA E
SILVA MAIA
Avaliadora

MONTES CLAROS – MG
2007
 III

AGRADECIMENTOS

Em especial ao meu orientador João

Batista Mendes pelos ensinamentos e
dedicação, que foram importantes durante
o desenvolvimento da pesquisa.
À coordenadoria do curso de Sistemas de
Informação por ter disponibilizado o
laboratório II para a realização dos testes.
E agradeço a Deus pela saúde e
disposição que Ele me concedeu.
 IV

RESUMO

Os Sistemas Gerenciadores de Bancos de Dados (SGBDs) oferecem grandes

benefícios às organizações quando são projetados para realizar a tarefa proposta.
Por isto, a escolha do sistema deve ser analisada com cautela, observando as
vantagens e desvantagens de cada sistema. Um fator que é alvo de polêmica entre
os usuários de bancos de dados é o desempenho que cada SGBD oferece. Para
comparar o desempenho de sistemas é importante que benchmarks sejam feitos, e
nesta linha de pesquisa o trabalho foi desenvolvido. Este trabalho apresenta uma
análise da performance entre os bancos de dados PostgreSQL (versão 8.2) e
Firebird (versão 1.5), na plataforma Windows 2000, com o intuito de ajudar os
usuários de bancos de dados na escolha do melhor sistema para a sua aplicação.
Para analisar os sistemas foram implementadas um conjunto de aplicações que
fazem inserção e seleção em cada banco, executadas em cenários mono-usuário e
multi-usuário. Ao final, percebeu-se que o sistema PostgreSQL apresenta um
desempenho superior ao do Firebird em todas as operações.
 V

SUMÁRIO

1 INTRODUÇÃO ............................................................................................9
2 SISTEMAS GERENCIADORES DE BANCOS DE DADOS (SGBDS) .....11
2.1 SISTEMAS DE BANCO DE DADOS ............................................................................. 11
2.2 POSTGRESQL ......................................................................................................................... 12
2.2.1 Descrição ........................................................................................................12
2.2.2 Histórico..........................................................................................................13
2.2.3 Características................................................................................................14
2.2.4 Arquitetura ......................................................................................................15
2.2.5 Exemplos ........................................................................................................16
2.3 FIREBIRD ................................................................................................................................... 16
2.3.1 Descrição ........................................................................................................16
2.3.2 Histórico..........................................................................................................17
2.3.3 Características................................................................................................17
2.3.4 Arquitetura ......................................................................................................18
2.3.5 Exemplos ........................................................................................................19
3 BENCHMARK...........................................................................................21
3.1 DESCRIÇÃO ............................................................................................................................. 21
3.2 ORIGEM ...................................................................................................................................... 22
3.3 EXEMPLOS ............................................................................................................................... 23
3.3.1 Benchmarks TPC............................................................................................23
3.3.2 Benchmark AS3AP e OSDB ...........................................................................25
4 PHP...........................................................................................................26
4.1 DEFINIÇÃO................................................................................................................................ 26
4.2 HISTÓRICO ............................................................................................................................... 27
4.3 SERVIDOR WEB APACHE................................................................................................ 28
5 TRABALHO DESENVOLVIDO.................................................................30
5.1 DETALHES DO CENÁRIO E CONFIGURAÇÕES ................................................. 30
5.2 BENCHMARK ........................................................................................................................... 31
5.3 STORED PROCEDURE ...................................................................................................... 35
5.3.1 Descrição ........................................................................................................35
6 RESULTADOS..........................................................................................37
 VI

7 CONCLUSÕES E TRABALHOS FUTUROS ............................................40

REFERÊNCIAS BIBLIOGRÁFICAS .........................................................41
 VII

LISTA DE FIGURAS

Figura 2.1 – Representação do Acesso ao Banco de Dados. ...................................12

Figura 4.1 – Ambiente de Análise dos SGBDs..........................................................29
Figura 5.1 – Estrutura da Tabela Alunos. ..................................................................30
Figura 5.2 – Função que Calcula o Tempo de Execução..........................................32
Figura 5.3 – Conexão do PHP e o Firebird. ..............................................................33
Figura 5.4 – Conexão do PHP e o PostgreSQL. .......................................................33
Figura 5.5 – Código da Consulta ao Banco de Dados. .............................................34
Figura 5.6 – Código da Stored Procedure para Inserção no Firebird. .......................35
Figura 5.7 – Código da Stored Procedure para Inserção no PostgreSQL.................35
 VIII

LISTA DE TABELAS

Tabela 6.1 – Resultado dos Testes de Conexão.......................................................37

Tabela 6.2 – Resultado dos Testes de Inserção. ......................................................37
Tabela 6.3 – Resultado dos Testes de Seleção. .......................................................38
Tabela 6.4 – Resultado dos Testes de Inserção com Stored Procedure. .................39
 9

1 INTRODUÇÃO

A escolha de um Sistema Gerenciador de Banco de Dados (SGBD) dentre a

grande diversidade disponível no mercado é uma tarefa delicada, devido à
importância e responsabilidade que essa ferramenta representa por gerenciar uma
das maiores riquezas de uma organização, que são as informações.
Nesta tarefa, vários fatores devem ser considerados, tais como confiabilidade,
integridade e segurança dos dados, suporte à linguagem de programação,
interoperabilidade, conjunto de ferramentas do produto, dentro outros. Com o
crescimento constante do volume de dados que os SGBDs gerenciam, e que muitas
vezes estão armazenados remotamente, um fator que vem se destacando como
ponto decisivo para escolha de um sistema é o desempenho. Sendo realmente uma
questão de discussão entre os usuários de Banco de Dados o desempenho
proporcionado pelo mesmo.
Existe uma preocupação com qual sistema de banco de dados é melhor do
que o outro diante de situações práticas, com qual sistema oferece tempos de
resposta menores. Isto provoca o interesse em desenvolver trabalhos de análise
entre os mesmos.
No escopo de desempenho de sistemas de bancos de dados, este trabalho
apresenta uma análise entre os bancos PostgreSQL (versão 8.2) e Firebird (versão
1.5), no Windows 2000, para auxiliar os usuários de bancos de dados quanto à
escolha do SGBD mais adequado e solucionar a dúvida de como os sistemas
Firebird e PostgreSQL se comportam em uma bateria de testes.
O ambiente utilizado na análise é composto por um servidor de páginas
Apache (versão 2.2), interagindo com a linguagem de programação PHP (versão
5.2), a qual irá interagir diretamente com os bancos de dados.
A escolha destes sistemas é justificada pela habilidade apresentada em
manipular grandes volumes de dados, por possuírem objetivos de projetos
semelhantes (esses sistemas foram construídos para fazer tarefas de negócio
críticas) e, principalmente, por serem sistemas de código aberto, que estão
disponíveis para a comunidade utilizar.
 10

O trabalho desenvolvido teve por objetivo apresentar o sistema com melhor

performance, observar o comportamento de cada sistema de banco de dados numa
aplicação desenvolvida em PHP, e validar as formas de comunicação de cada um
com esta linguagem. Além de compreender o comportamento dos sistemas em
ambientes mono-usuário e multi-usuário, e descrever algumas tecnologias de
benchmarks presentes na literatura.
Trabalhos similares a este foram desenvolvidos comparando os sistemas
Firebird e o MySQL, ou o PostgreSQL e o MySQL. Mas o MySQL não deve ser
confrontado com estes sistemas, pois foi projetado para aplicações Web e não para
fazer tarefas complexas como no caso dos dois sistemas citados.
Para apresentar esta análise, o material foi estruturado como segue: o
capítulo 2 esclarece a finalidade dos Sistemas Gerenciadores de Banco de Dados
(SGBDs) e expõe as características e evolução dos sistemas que serão avaliados.
No capítulo 3 são discutidos os conceitos envolvendo avaliação de desempenho e
benchmarks. O capítulo 4 faz uma explanação sobre a linguagem PHP e o servidor
web Apache. O capítulo 5 descreve o ambiente construído para aplicação dos
testes, a implementação do benchmark e as métricas avaliadas. Os resultados
obtidos com os testes são apresentados no capitulo 6. O capítulo 7 apresenta as
conclusões e perspectivas de trabalhos futuros.
 11

2 SISTEMAS GERENCIADORES DE BANCOS DE DADOS (SGBDS)

Este capítulo esclarece a finalidade dos Sistemas Gerenciadores de Banco de

Dados (SGBDs) e expõe as características e evolução dos sistemas que serão
avaliados.

2.1 SISTEMAS DE BANCO DE DADOS

A informação é um elemento fundamental em toda atividade humana. Através

dela decisões são tomadas, planejamentos e controles são feitos. Cavalcanti (1995)
apresenta uma dinâmica interessante dos benefícios que a disponibilidade e
agilização do fluxo de informações nas organizações acarretam. Mostrando que
através da informação a empresa tenderá a ter as suas decisões mais rápidas e,
muito provavelmente mais acertadas, gerando assim mais lucros, mais crescimento,
mais empregos, possibilidade de maiores salários, contribuição para um aumento de
poder aquisitivo da região onde está localizada, e uma melhor qualidade de vida.
O Banco de Dados é um recurso que veio facilitar a busca de informações,
eliminando os arquivos de papéis, integrando os dados de aplicações e fornecendo
segurança. Com o objetivo de simplificar a criação e manutenção de um Banco de
Dados surgiu os Sistemas Gerenciadores de Banco de Dados (SGBDs).
Segundo Date (2000), os Sistemas de Banco de Dados tem a finalidade de
gerenciar as informações de um banco de dados, que é um repositório para uma
coleção de arquivos de dados computadorizados. Sendo assim, é uma camada que
fica entre o banco de dados e os usuários, ou outros softwares que interagem com o
SGBD, como mostrado na Figura 2.1.
 12

Figura 2.1 – Representação do Acesso ao Banco de Dados.Fonte Própria

Um SGBD fornece aos usuários operações para inserir, alterar, excluir, obter
e atualizar dados em um sistema, assegurando a integridade dos dados. Sua
utilização traz inúmeras vantagens como: eficiência no acesso aos dados, redução
do tempo de desenvolvimento de uma aplicação, acesso concorrente e rápido
retorno, além da integridade e segurança dos dados.

2.2 POSTGRESQL

2.2.1 Descrição

O PostgreSQL é definido como um Sistema Gerenciador de Banco de Dados

objeto-relacional, por apresentar características de um SGBD relacional e ainda,
funcionalidades de orientação a objetos (POSTGRESQL GLOBAL DEVELOPMENT
GROUP, 2005).
Com 21 anos de desenvolvimento e uma combinação de esforços de uma
grande comunidade de programadores espalhada pelo mundo, o PostgreSQL é um
sistema de código aberto que está concorrendo com produtos comerciais como SQL
Server e Oracle.
Por se tratar de um código aberto, com licença BSD (Berkeley Software
Distribution), o sistema possibilita o acesso, alterações e adaptações no código por
seus próprios usuários, exigindo somente que o código licenciado mantenha suas
informações de direitos autorais e licença. O PostgreSQL pode ser adquirido através
de download do site: http://www.postgresql.org/.
 13

2.2.2 Histórico

O PostgreSQL consiste em uma evolução do pacote Postgres, um projeto

iniciado em 1986 na Universidade da Califórnia, em Berkeley, sob a liderança do
professor Michael Stonebraker (extraído do site oficial do sistema1).
O objetivo do projeto Postgres era criar um servidor de banco de dados
relacional, tendo como base o projeto Ingres, também da Universidade de Berkeley.
Foi patrocinado por algumas empresas e instituições de inteligência norte-americana
como: DARPA (Defense Advanced Research Projects Agency), ARO (Army
Research Office), NSF (National Science Foundation) e ESL, Inc.
Como resultado do projeto desenvolvido, foi apresentada em 1987 a primeira
versão de demonstração do sistema Postgres. Entretanto, esta versão mostrou uma
limitação no sistema de regras.
Na tentativa de melhorar o Postgres, o sistema de regras foi reprojetado e a
versão 2 lançada em 1990. Posteriormente, foi adicionado suporte a múltiplos
gerenciadores de armazenamento, um executor de comandos melhorado e um
sistema de regras reescrito, surgindo a versão 3 em 1991. As versões seguintes do
Postgres até a sua comercialização visaram à portabilidade e a confiabilidade.
Em 1992, a Illustra Information Technologies (hoje, pertencente à IBM)
comprou e comercializou a tecnologia Postgres. No ano seguinte, a empresa
constatou que a manutenção e suporte do sistema exigiam um tempo que poderia
ser aplicado em estudos sobre banco de dados, e observou ainda, uma grande
expansão da comunidade de usuários. Diante deste cenário, a Illustra finalizou o
projeto com a versão 4.2.
Em 1994, o projeto foi reaberto por Andrew Yu e Jolly Chen, que aprimoraram
sua implementação dando ênfase ao desempenho e a facilidade de manutenção. Foi
adicionado um interpretador da linguagem SQL, seu código foi escrito em ANSI C e
reduzido 25% em tamanho, surgindo assim o Postgres95.
Segundo o site oficial do sistema postgresql, a performance do Postgres95 foi
melhorada em até 50% em relação ao Postgres versão 4.2, pelo Wisconsin
Benchmark. Além disso, algumas alterações no seu código merecem destaque
como:
1
http://www.postgresql.org/
 14

• inclusão de um programa de terminal interativo chamado psql;

• o sistema de arquivos Inversão e o sistema de regras no nível de instância
foram removidos;
• foi acrescentado ao código fonte um tutorial introduzindo as
funcionalidades da linguagem SQL e do Postgres95;
• subconsultas podiam ser simuladas por meio de funções SQL definidas
pelo usuário;
• funções de agregação foram reimplementadas;
• foi adicionado suporte à cláusula GROUP BY nas consultas;
• acrescentado uma nova biblioteca cliente, a libpgtcl, para suporte a
clientes baseados no Tcl, e novos comandos Tcl ao interpretador pgtclsh
para interfacear programas Tcl com o servidor Postgres95.
Em 1996, o nome Postgres95 foi modificado para PostgreSQL, com o intuito
de representar sua origem (Postgres) junto com a capacidade SQL. Sua versão foi
iniciada em 6.0, para manter uma seqüência dos números das versões desde o
projeto Postgres.
Além de um novo nome, o projeto recebeu algumas melhorias, onde citamos:
• os tipos usuais foram aperfeiçoados;
• flexibilidade através da inclusão de funções como: restrição, gatilho,
subconsulta e padrão no servidor.
Atualmente, está disponibilizada a versão 8.2 do sistema PostgreSQL.

2.2.3 Características

O PostgreSQL segue a padronização SQL (Strutured Query Language), uma

linguagem de interface para SGBD. Possui uma ferramenta texto chamada psql,
para receber os comandos SQL e uma interface gráfica chamada PGAdmin para
tornar mais fácil e intuitivo o uso do SGBD.
O sistema possibilita também a manipulação dos dados armazenados através
de camadas ODBC e JDBC ou com acesso nativo na linguagem C. Dada estas
 15

características, é possível desenvolver aplicações complexas para a manipulação de

dados armazenados no PostgreSQL, usando qualquer linguagem de programação,
como C/C++, Delphi, Java, Perl, PHP, Python, Visual Basic, e outras (NETO, 2003).
São listadas a seguir as principais características do sistema PostgreSQL:
• pode ser executado em vários sistemas operacionais, como Windows,
Mac OS X, Linux e outras variantes de Unix;
• suporta os tipos SQL padrão: int, smallint, real, double, precision, char(N),
varchar (N), date, time, timestamp, interval, e apresenta também uma
extensão denominada POSTGIS, que possibilita o armazenamento de
dados espaciais (ponto, linha, polígono, coleções geométricas e outros
objetos);
• pode ser estendido pelo usuário através da inclusão de novos tipos de
dados, funções, operadores, funções de agregação, métodos de índice e
linguagens procedurais;
• oferece: controle de simultaneidade multiversão, chaves estrangeiras,
gatilhos, visões, integridade transacional, técnicas de segurança (backup,
espelhamento de discos, cluster), herança e polimorfismo.

2.2.4 Arquitetura

O PostgreSQL utiliza o modelo cliente-servidor. Uma sessão consiste na

cooperação entre dois processos: o processo servidor, chamado postmaster, que
recebe conexões das aplicações clientes com o banco de dados e executa ações no
banco em nome dos clientes, e o processo cliente (postgres), que deseja executar
operações de banco de dados (POSTGRESQL GLOBAL DEVELOPMENT GROUP,
2005).
O servidor PostgreSQL pode tratar várias conexões simultâneas de clientes,
sendo iniciado um processo filho para cada conexão (thread independente do
postmaster). Deste ponto em diante, o cliente e o processo filho se comunicam sem
interferência do processo postmaster original. Portanto, o postmaster está sempre
 16

em execução aguardando por novas conexões dos clientes, enquanto os clientes e

suas threads associadas surgem e desaparecem.
A comunicação entre o postmaster e os processos filhos (postgres) acontece
por meio de IPC (interprocess communication) e são utilizadas variáveis globais para
gerenciar o acesso aos recursos do sistema.

2.2.5 Exemplos

Casos de uso como o DETRAN - PR, Embrapa - Empresa Brasileira de

Pesquisa Agropecuária, Companhia do Metropolitano de São Paulo, Shannon
Medical Center e Mohawk Software mostram que grandes empresas adotaram o
sistema PostgreSQL (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2005).

2.3 FIREBIRD

2.3.1 Descrição

O Firebird é um sistema de manutenção de bases de dados sustentado pelo

trabalho voluntário de um grupo de desenvolvedores e pela Fundação FireBird.
O sistema Firebird está disponível no site http://firebird.sourceforge.net/ para
download. E por ser um projeto de código aberto, os usuários podem contribuir
implementando novos recursos e corrigindo erros.
 17

2.3.2 Histórico

O sistema Firebird é oriundo do projeto Groton, iniciado em 1985 por uma

equipe de engenheiros da DEC (Digital Equipament Corporation). A idéia era
desenvolver um Sistema Gerenciador de Bancos de Dados Relacional que
oferecesse benefícios não encontrados nos sistemas existentes.
O Groton passou por várias alterações, sendo renomeado em 1986 como
Interbase 2.0 e introduzido algumas características como: acesso nativo a driver
JDBC, commit automático de duas fases, sombreamento do banco de dados,
replicação, tratamento de blob´s e sistema de eventos.
No ano de 2000, a Borland, empresa fabricante do Interbase, decidiu
disponibilizar o código do Interbase versão 6.0 (as versões subseqüentes são
proprietárias e pagas). Em virtude deste acontecimento, alguns programadores se
reuniram para analisar e melhorar o código do sistema, fazendo parte da equipe:
Ann Harrison e Jim Starkey, idealizador do Interbase.
Como resultado do trabalho dessa equipe surgiu o Firebird, um sistema
gerenciador de banco de dados estável e seguro, projetado para fazer transações
financeiras e tarefas de negócio críticas (extraído do site:
http://www.firebird.com.br/wiki/).
Atualmente encontra-se em testes a versão 2.1 (Alpha). No Brasil, o grupo
FireBase oferece suporte gratuito na solução de problemas e dúvidas.

2.3.3 Características

O sistema Firebird oferece um conjunto de características importantes como:

utiliza o padrão ANSI SQL-92, está disponível para os principais sistemas
operacionais (Windows, Linux, Solaris, MacOS), suporte a stored procedures e
triggers, replicação, integridade referencial entre tabelas, backups incrementais,
 18

transações compatível com ACID (Atomicidade, Consistência, Isolamento,

Durabilidade), UDF (User Defined Functions) e SubSelects.
Além disso, o Firebird apresenta pouca ocupação de espaço em disco (10,33
Mb) e utiliza pouca memória em situações normais de uso.
As opções mais conhecidas de ambiente gráfico do Firebird são o IBExpert,
IBOConsole e Firebird Workbench.

2.3.4 Arquitetura

As modificações no código do Interbase 6.0 para a criação do Firebird não

afetaram a sua arquitetura baseada em processos. Foi mantida a arquitetura
Classic, desenvolvida para a versão 4.0 do Interbase.
No modelo Classic, cada conexão inicia um processo de servidor com um
cache de banco de dados. A disputa entre os processos para acessar o banco é
solucionada por um outro processo, que permanece sempre em execução
garantindo aos clientes o travamento de recursos do banco (IBPHOENIX, 2002).
Posteriormente foi implementada uma nova arquitetura para o Firebird, a
SuperServer. Utilizando o recurso de threads, esta arquitetura eliminou os processos
separados para cada cliente. Agora, várias threads compartilham um único processo
de servidor, que é capaz de reconhecer todos os clientes que estão conectados.
Enquanto que na Classic, cada processo no servidor conhece somente a sua
conexão.
Os benefícios do modelo SuperServer são grandes. Foi melhorada a
performance e integridade do banco, afinal só um processo de servidor passa
acessá-lo. A existência deste único processo desencadeia vários ganhos no
sistema. Como foi eliminada a criação de um processo para cada cliente conectado,
junto deixa de existir o cache das páginas do banco na memória do processo, e
conseqüentemente não existem dados duplicados armazenados no sistema.
O modelo SuperServer usa um único espaço de cache para todas as ligações
de cliente. Por isso, o processo cliente não abre diretamente o arquivo de banco de
 19

dados, sendo cada conexão recebida por uma thread e utilizado uma thread
especializada para gerenciar o acesso concorrente aos dados.
Com menos sobrecarga e utilizando menos recursos por conexão de clientes
que a arquitetura Classic, a SuperServer possibilitou ao Firebird servir de modo mais
eficiente um grande número de clientes concorrentes. A configuração Classic é
utilizada em sistemas operacionais que não executam aplicações multi-thread e em
algumas situações específicas indicada para máquinas com mais de um
processador.
Já o modelo Embedded, ou embarcado, é um servidor Firebird completo que
não necessita de instalação. Possibilita criar aplicativos com o Firebird adicionado de
forma transparente, eliminando a alternativa de ter que instalar o Firebird para
acessar a sua base de dados. Essa versão veio facilitar o processo de distribuição
de programas, pois a execução já é suficiente para o acesso ao banco.
No quesito segurança, a arquitetura Embedded não implementa nenhum
mecanismo de autenticação, a senha é ignorada. Ideal para distribuição de
catálogos eletrônicos, programas com acesso a dados não compartilhado e versões
de demonstração.
Portanto, encontramos o servidor Firebird em três versões: Classic Server,
SuperServer (que veio substituir o modelo Classic) e o Embedded, que é uma
solução para os problemas de distribuição do sistema e não uma evolução da
arquitetura visando descartar a anterior, como no caso da Classic e SuperServer.

2.3.5 Exemplos

Na seqüência são listadas algumas empresas que usam o Firebird em seus

softwares, extraído do site da FireBase:
• CAEMA – Cia. de Águas e Saneamento do Estado do Maranhão;
• CEAL – Companhia Energética de Alagoas;
• CODECA – Cia. de Desenvolvimento de Caxias do Sul;
• Copervale;
 20

• SBC – Sociedade Brasileira de Computação;

• MultiBank S/A.
 21

3 BENCHMARK

Este capítulo define os conceitos relacionados à avaliação de desempenho e

benchmarks, onde são descritos os principais benchmarks usados para analisar
Sistemas Gerenciadores de Banco de Dados.

3.1 DESCRIÇÃO

A avaliação de um sistema computacional abrange desde aspectos

funcionais, como desempenho e sistema operacional suportado, até aspectos sócio-
culturais, como adaptação do usuário a ferramenta (SILVA, 2004).
Segundo Svobodova (1976), a finalidade da avaliação de desempenho de um
sistema é verificar a efetividade com que os recursos de hardware são utilizados
para atender aos objetivos do software. Esta avaliação pode ser classificada como
Comparativa, quando o desempenho do sistema é avaliado mediante o desempenho
de outro sistema, ou Analítica, quando o sistema é avaliado com vários parâmetros
de carga e de configuração do próprio sistema.
Um benchmark consiste em um padrão de testes para medir ou avaliar algo,
sendo utilizado também para analisar o desempenho de um sistema. Pode ser
implementado como uma instrução, um programa ou uma seqüência de pedidos de
interações com um componente de software.
Os programas de benchmark efetuam um número de operações pré-definidas
(carga de trabalho) e apresenta um resultado em algum formato (métrica), que relata
o comportamento do sistema (PIRES; NASCIMENTO; SALGADO, 2006). As
métricas podem calcular a velocidade para completar a carga de trabalho ou vazão
(quantas cargas de trabalho por unidade de tempo foram medidas).
Segundo Gray (1993), um benchmark deve atender os seguintes critérios:
• relevância: As medidas verificadas deverão descrever funcionalidade e
expectativa de desempenho acerca do produto submetido ao benchmark.
 22

É necessário especificar com clareza o domínio da utilização da

ferramenta e as operações a serem submetidas;
• portabilidade: Na elaboração de um benchmark, as definições e os termos
utilizados devem estar em um nível de abstração que permita transportá-lo
para as implementações de diferentes ferramentas. Portanto, não deve
haver privilégio na utilização de um contexto que seja particular a uma
determinada abordagem. O objetivo desta consideração é tornar o
benchmark aplicável a uma gama maior de ferramentas a serem
avaliadas;
• escalabilidade: O padrão das medições deve atender a pequenos ou
grandes sistemas, independente do nível de complexidade dos mesmos.
Fatores como monoprocessamento ou multiprocessamento, clock e
tamanhos de memórias não devem tornar as medidas inconsistentes, nem
influenciar na aplicabilidade do benchmark;
• simplicidade: Os critérios definidos no benchmark devem ser simples e de
fácil compreensão. Porém, a relevância das métricas não deve ser
negligenciada. Medidas muito simples podem não refletir boas
características de julgamento de uma ferramenta. No entanto, se for
definido um conjunto de métricas muito complexas e de difícil assimilação
pela comunidade interessada nos resultados, poderá ocorrer uma perda
de credibilidade do benchmark.

3.2 ORIGEM

Desde 1970, estudos dentro de empresas são realizados com o objetivo de

aumentar os rendimentos. Estas análises eram feitas através da identificação interna
de pessoas ou departamentos que melhores resultados obtiveram, ou identificação
de modelos a seguir dentro das suas concorrentes para disseminar na empresa.
 23

Mas é no final dos anos 80 que surge o termo benchmarking, derivado da

palavra benchmark, que significa uma marca feita por agrimensor, indicando um
ponto em uma linha de nível, um padrão ou um ponto de referência.
Esse termo sugere um processo estruturado de investigação de
oportunidades de melhorias internas e um processo de aprendizagem, onde são
esforços de mudança para melhorar o desempenho de acordo com as conclusões
do estudo.
O benchmarking surgiu como uma ferramenta para a qualidade, com o
objetivo de gerar vantagem competitiva.

3.3 EXEMPLOS

Existem várias implementações de benchmarks para realizar medidas de

desempenho, nos mais diversos sistemas, como servidores WEB, SGBDs,
aplicações gráficas, entre outros.
Como exemplo, pode-se citar: benchmarks para banco de dados (AS3AP,
DBT-2, OSDB, TPCC-UVA, TPC, Wiscosin, 007) e benchmarks para arquiteturas de
CPUs (SPEC 95, SPEC 2000).
A seguir são descritos os principais benchmarks utilizados para avaliar
Sistemas Gerenciadores de Banco de Dados.

3.3.1 Benchmarks TPC

Com o objetivo de definir benchmarks para avaliar o processamento de

transações e banco de dados, surgiu em 1988 o TPC (Transaction Process Council).
O TPC é um consórcio sem fins lucrativos, que realiza avaliações em ambientes
diferentes e publica relatórios de benchmarks denominados: TPC-C, TPC-H, TPC-W
 24

e TPC-App. O conjunto de transações que compõem os testes é o que diferencia os

diversos relatórios TPCs (TPC, 2004).
O Benchmark TPC-C é utilizado para avaliar Sistemas Gerenciadores de
Banco de Dados (SGBDs). É definida uma carga de processamento de transações
on-line que simula as atividades encontradas em um ambiente de aplicações
complexas, caracterizado por:
• execução simultânea de múltiplos tipos de transações;
• múltiplas sessões;
• entrada / Saída de disco significantes;
• integridade da transação (propriedade ACID);
• distribuição não-uniforme de acessos aos dados;
• banco de Dados consistindo de muitas tabelas, com uma grande
variedade de tamanhos, atributos e relacionamentos;
• concorrência no acesso aos dados.
A métrica de desempenho definida é uma taxa medindo o número de
transações efetivadas com sucesso por minuto (tpmC). Múltiplas transações são
utilizadas para simular a atividade do negócio.
Já o TPC-H avalia o suporte da base de dados para um sistema de apoio a
decisões, Data Warehouse (MACHADO, 2004). É analisado o desempenho do
banco de dados no processamento de grandes quantidades de dados
convencionais, através de consultas que simulam a atividade real, como perguntas
sobre épocas de promoções, lucro possível, entre outros.
O TPC-W avalia as atividades de um servidor WEB, simulando um comércio
eletrônico pela Internet. Atualmente foi substituído pelo TPC-App, que abrange todas
as características e possibilidades de negócio dos servidores Web, como por
exemplo, capacidade de conexões e gerenciamento de transações (TPC-APP,
2005).
 25

3.3.2 Benchmark AS3AP e OSDB

As características do AS3AP (TURBYFILL, 1992) que o destaca são: a

amplitude na medição do desempenho das principais funcionalidades de um banco
de dados, e a variação de tipos de carga de trabalho aplicados.
O AS3AP é estruturado em módulos, sendo cada módulo responsável por
testar uma funcionalidade, podendo inclusive, os módulos serem executados em
conjunto.
O OSDB (Open Source Database Benchmark) é um benchmark de código
aberto baseado no AS3AP. Criado com o intuito de avaliar a taxa de I/O
(input/output) e o poder de processamento da plataforma GNU Linux/Alpha, o OSDB
apresenta algumas diferenças em relação ao AS3AP, como quantidade de métricas
retornadas e número de módulos.
Enquanto a avaliação dos resultados gerados pelo AS3AP baseia-se em uma
única métrica (tamanho máximo do banco de dados suficiente para completar o teste
em menos de 12 horas), o OSDB possibilita a comparação através de outras
métricas: tempo de resposta das consultas e número de linhas retornadas por
segundo (PIRES; NASCIMENTO; SALGADO, 2006).
 26

4 PHP

Este capítulo discorre sobre o conceito e evolução da linguagem PHP, e

apresenta o servidor web Apache.

4.1 DEFINIÇÃO

A comunicação na Web utiliza o modelo cliente/servidor, que consiste na

interação de dois componentes: o cliente HTTP, que solicita arquivos (páginas) ao
servidor, e o servidor HTTP, que disponibiliza as informações requeridas. Este
processo de comunicação utiliza o protocolo de transferência HTTP (HyperText
Transfer Protocol), que padroniza o modo de envio e recebimento de dados
garantindo independência de plataforma (KINOSHITA, 2001).
As informações (páginas) que o servidor disponibiliza, podem se apresentar
estáticas, quando apresentam sempre o mesmo conteúdo e não permitem a
interação com o usuário, ou dinâmicas, quando são geradas em tempo de execução
(on-line) em resposta a uma solicitação do usuário.
Para gerar páginas dinâmicas na Web são usados programas auxiliares
denominados Scripts Web, que são processados na plataforma do servidor. Scripts
Web são responsáveis pela interação entre o banco de dados e o servidor Web.
Entre as opções de ferramentas (Scripts Web) que podem ser usadas para a
geração de páginas dinâmicas está o PHP (Hypertext Preprocessor).
O PHP é uma linguagem de criação de scripts, cujo código é inserido dentro
do código HTML, e processado no servidor, sendo retornado para o cliente apenas
HTML (KINOSHITA, 2001).
Os produtos patenteados nesse nicho do mercado são o ASP (Active Server
Pages) da Microsoft, o Coldfusion da Allaire e o JSP (Java Server Pages) da Sun.
Uma característica importante do PHP para este trabalho é o grande número
de banco de dados suportados como: Adabas D, dBase, Empress, FilePro, Firebird,
 27

Informix, Interbase, mSQL, MySQL, Oracle, PostgreSQL, Sybase, Velocis, dentre

outros. Além disso, o PHP é compatível com várias plataformas, podendo ser
utilizado tanto em Windows como em Linux.
Este produto pode ser adquirido através do site oficial: http://www.php.net,
sem custo de licença.

4.2 HISTÓRICO

O desenvolvimento da linguagem PHP (Personal Home Page) começou em

1994 com Rasmus Lerdorf, engenheiro de software. A criação deste script Web foi
estimulada pelo interesse de Rasmus em ter informações sobre quem acedia à sua
página pessoal.
Buscando melhorias no projeto PHP, foi adicionado ao pacote: o FI e suporte
a mSQL, sendo lançada à versão 2.0 com o nome de PHP/FI, em 1995. O FI (Form
Interpreter) usava interpretação automática de variáveis vindas de formulário e
sintaxe embutida no HTML, possibilitando aos usuários desenvolver simples
aplicativos dinâmicos para Web (extraído do site oficial1).
Em 1997, devido à extensão que o PHP estava atingindo, uma equipe de
desenvolvimento assumiu o projeto PHP, seguindo o modelo de código-fonte aberto
com contribuições de desenvolvedores e usuários em todo o mundo.
Assim, Zeev Suraski e Andi Gutmans, programadores israelenses,
reescreveram o PHP, aproveitando parte do código do PHP/FI, lançando em 1998 a
versão 3.0. O PHP 3.0 oferecia aos usuários uma infra-estrutura sólida para diversos
bancos de dados, suporte a novos protocolos de Internet e APIs, suporte à sintaxe
para orientação a objetos, mas sua principal característica era a capacidade de
extensibilidade.
Na versão 4.0, implantada em 2000, foram incluídos suporte para muitos
servidores Web, sessões HTTP, buffer de saída, maneiras mais seguras de

1
http://www.php.net/
 28

manipular input de usuários e um melhoramento da performance. O PHP 4.0

também foi criado por Suraski e Gutmans, que basearam na tecnologia Zend.
A melhora da performance desta versão foi devido à mudança do
procedimento do PHP 3.0, que analisava e executava o código ao mesmo tempo. No
PHP 4.0, todo o código é compilado e convertido em byte code, e posteriormente
processado pelo Zend Engine.
No ano de 2002, a versão 4.3.0 do PHP incluiu inovações como: suporte a
streams (camada de entrada e saída de arquivos e de rede), CLI (Interface de Linha
de Comando) e a biblioteca GD (tratamento de imagens).
A versão 5.0 do PHP foi disponibilizada em julho de 2004, trazendo como
destaque a orientação a objetos totalmente reescrita e funcionalidades como
SimpleXML, SOAP e MySQLi.
Atualmente o PHP está na versão 5.2.3.

4.3 SERVIDOR WEB APACHE

Um servidor Web corresponde a um programa que está sempre em execução

esperando por requisições realizadas a partir do “cliente” e responsável pelo retorno
dos dados solicitados.
O mercado oferece mais de 500 servidores Web, que diferenciam pelo tipo de
distribuição, desempenho, suporte técnico e módulos disponíveis. Dentro destas
várias opções de ferramentas, encontra-se o Servidor Apache.
Implementado pela equipe The Apache Team em 1995, o Apache é hoje um
líder no segmento de servidores Web. Esta posição de destaque é justificada nas
características que o Apache apresenta como: livre distribuição e facilidade do
processo de instalação, disponível para várias plataformas (Windows, Unix Like,
Solaris, Sun), suporte à utilização de protocolos de transferência de arquivos com
segurança e grande flexibilidade (extraído do site: http://www.apache.org/). Além
destas qualidades, a facilidade de configuração do PHP com o servidor Apache foi
um ponto importante para a escolha do mesmo.
 29

O ambiente utilizado neste estudo para análise dos SGBDs é composto pelo
servidor Apache interagindo com a linguagem PHP, a qual irá acessar os bancos de
dados, como ilustra a figura 4.1.

Figura 4.1 – Ambiente de Análise dos SGBDs.

 30

5 TRABALHO DESENVOLVIDO

Neste capítulo são descritos o ambiente construído para aplicação dos testes,
a implementação do benchmark e as métricas avaliadas.

5.1 DETALHES DO CENÁRIO E CONFIGURAÇÕES

Para analisar o desempenho de cada banco, primeiramente, foi criado um

banco de dados com o nome Unimontes contendo uma tabela denominada Alunos,
com a estrutura similar à apresentada na Figura 5.1.

MATRICULA NOME CONTROLE

Figura 5.1 – Estrutura da Tabela Alunos.

O campo MATRICULA é um campo auto-incremento de números inteiros e

seqüenciais, que foi construído no Firebird criando um Generator através do
comando CREATE GENERATOR. Este campo é incrementado toda vez que a
função gen_id() é chamada.
Para esse mesmo resultado, no PostgreSQL foi criada uma seqüência através
do comando CREATE SEQUENCE, que é incrementada toda vez que a função
nextval é chamada.
O campo NOME é do tipo VARCHAR e o campo CONTROLE é do tipo
BIGINT, que está recebendo um valor aleatório.
Em seguida foi desenvolvido um conjunto de aplicações (carga de trabalho do
benchmark) que fazem as seguintes operações:
• inserção de 10.000 registros na tabela Alunos;
• seleção de 1.000 alunos da base;
• inserção de 100.000 alunos;
 31

• seleção de 10.000 alunos desta base.

Os testes foram aplicados em dois ambientes diferentes, o primeiro foi o
mono-usuário, composto por uma aplicação cliente que realizou as operações de
inserção e seleção sobre cada um dos SGBDs. O segundo ambiente foi composto
por 05 (cinco) estações clientes, que realizaram operações de inserção e consulta
de dados em cada sistema. Para análise de desempenho foi considerada a métrica:
tempo de resposta em segundos.
Em cada cenário as aplicações foram executadas 10 (dez) vezes e coletados
os tempos resultantes das operações. Com estes resultados foi calculado o tempo
médio que cada SGBD utiliza para execução das operações.
O ambiente de análise foi implementado em uma máquina com processador
AMD Atlhon 2000, com 512 Megabytes de memória RAM e disco rígido de 40
Gigabytes. Todos os testes foram realizados no Laboratório II do Centro de Ciências
Exatas e Tecnológicas da Universidade Estadual de Montes Claros – UNIMONTES.

5.2 BENCHMARK

A aplicação de análise consiste em o PHP receber um pedido de inserção ou

consulta ao banco de dados, gravar em uma variável o tempo em que esta consulta
foi requisitada, solicitar ao SGBD a execução da mesma e guardar o tempo após a
execução do pedido. Com os dois pontos de tempo coletados, calcula-se a diferença
entre eles e como resultado tem-se o tempo gasto na realização da consulta. A
Figura 5.2 apresenta o código que calcula o tempo da execução de uma tarefa.
 32

1 <?php
2
3 function tempo()
4 {
5 list($usec,$sec)=explode(" ",microtime());
6 return((float)$usec + (float)$sec);
7 }
8
9 $inicio=tempo();
10
11 echo "Aqui são incluídos os pedidos de acesso ao SGBD <br>";
12
13 $fim=tempo();
14
15 $tempoexec=($fim-$inicio);
16
17 echo "<p>Operação realizada em $tempoexec segundos </p>";
18 ?>
Figura 5.2 – Função que Calcula o Tempo de Execução.

A função tempo, compreendida entre a linha 3 e a linha 7, retorna o tempo

atual em segundos. Esta função utiliza uma outra função chamada microtime()
(PHP,2005), que retorna uma string “msec sec” onde sec é o tempo atual medido no
número de segundos desde a Era Unix (0:00:00 January 1,1970 GMT), e msec é a
parte em microssegundos. A função microtime() está disponível somente em
Sistemas Operacionais que suportam a chamada gettimeofday() (obtém a hora
local). A função explode() divide a string retornada pela função microtime() em duas
partes, que são somadas e retornada pela função tempo().
Na linha 9 a função tempo() é chamada e o retorno (tempo atual em
segundos) atribuído a variável $inicio. Em seguida, são incluídas todas as
operações que acessam ao banco de dados (carga de trabalho), e só após a
execução destas operações a variável $fim recebe o tempo atual, representado na
linha 13. Com isso conseguimos o tempo de duração das operações (métrica)
através da diferença entre a variável $fim e $inicio, apresentado na linha 15.
A conexão do PHP e o Firebird foi realizada pela função ibase_connect(),
disponibilizada pelo PHP, que recebe como parâmetros a localização do banco de
dados (nesta análise, Unimontes), o nome do usuário (SYSDBA) e a senha
(masterkey), como ilustrado na Figura 5.3. A conexão é encerrada pela função
ibase_close().
 33

$conexao = ibase_connect('localhost:c:/Arquivos de
programas/Firebird/Firebird_1_5/bin/Unimontes.gdb', 'SYSDBA','masterkey');

if($conexao){
echo '<p>Conexão realizada com sucesso!!!</p>';
ibase_close($conexao);
} else {
echo '<p>Falha na conexão.</p>';
}

Figura 5.3 – Conexão do PHP e o Firebird.

E para conectar o PHP e o PostgreSQL foi utilizada a função pg_connect, a

qual é disponibilizada pelo PHP para esse SGBD, e a função pg_close() para fechar
a conexão. A Figura 5.4 mostra o trecho do código, em PHP, utilizado para realizar a
conexão ao PostgreSQL.

$conexao = pg_connect("host =127.0.0.1 dbname=unimontes port=5432

user=postgres password=post");

if($conexao){
echo '<p>Conexão realizada com sucesso!!!</p>';
pg_close($conexao);
} else {
echo '<p>Falha na conexão.</p>';
}

Figura 5.4 – Conexão do PHP e o PostgreSQL.

O aplicativo que executa a consulta de 1.000 e 10.000 registros nos bancos

de dados utilizou uma variável chamada $mat, que recebe um valor randômico entre
1 e o tamanho da base de dados consultada. Representando assim todos os valores
do campo Matrícula existentes no banco de dados. Observe a linha 4 no trecho do
código de consulta apresentado na Figura 5.5. Neste exemplo estão sendo
selecionados 10.000 registros em uma base de 100.000 (Firebird).
 34

1 $quant=10000;
2 echo "<b>Matrícula - Nome - Controle</b><br>"
3 for($i=0; $i<$quant; $i++){
4 $mat=rand(1,100000);
5 $busca = "SELECT Matricula,Nome,Controle FROM Alunos WHERE
Matricula=$mat";
6 $retorno = ibase_query($conexao,$busca);
7
8 while ($linha = ibase_fetch_row($retorno)){
9 echo "$linha[0] - $linha[1] - $linha[2]<br>";}
10 }
}
Figura 5.5 – Código da Consulta ao Banco de Dados.

Na linha 1 do código apresentado acima, a variável $quant recebe o número

de registros a ser selecionado no banco de dados. A seleção ocorre na linha 6,
sendo retornado a variável $retorno o registro com campo da matrícula igual ao valor
gerado pela função rand(). As linhas 8 e 9 imprimem o resultado da seleção na tela.
O aplicativo que executa a inserção dos registros no banco de dados utiliza
uma variável também chamada de $quant, que recebe nesta pesquisa o valor
10.000 ou 100.000, representando o número de registros a serem inseridos. E utiliza
o comando for, usando a variável de controle que é incrementada a cada execução
até atingir o valor igual a $quant.
O desempenho dos SGBDs pode ser melhorado com a utilização de Stored
Procedures. Foi desenvolvida uma aplicação de inserção para testar o desempenho
dos sistemas utilizando este recurso. A seção 5.3 apresenta uma explicação sobre
Stored Procedure baseada no trabalho de Huth (2002). As Figuras 5.6 e 5.7
apresentam os códigos de criação de stored procedure nos sistemas Firebird e
PostgreSQL, respectivamente.
 35

CREATE PROCEDURE insercao (quant BIGINT)

AS
DECLARE VARIABLE i BIGINT;
BEGIN
i = 0;
WHILE (i<quant) DO BEGIN
INSERT INTO Alunos(Matricula,Nome,Controle) VALUES
(gen_id(gen_alunos_id,1), ‘Dayane Helen’, 3);
i = (i+1); END
END;
Figura 5.6 – Código da Stored Procedure para Inserção no Firebird.

CREATE OR REPLACE FUNCTION insercao (BIGINT)

RETURNS void
AS $$
DECLARE i BIGINT;
BEGIN
i := 0;
WHILE (i<$1) LOOP
INSERT INTO Alunos(Matricula,Nome, Controle) VALUES
(nextval(‘alunos_matricula_seq’), ‘Dayane Helen’,3);
i := (i+1);
END LOOP;
END; $$
LANGUAGE plpgsql;
Figura 5.7 – Código da Stored Procedure para Inserção no PostgreSQL.

5.3 STORED PROCEDURE

5.3.1 Descrição

Uma Stored Procedure (SP) é formada por uma ou mais instruções SQL
agrupadas e armazenadas no SGBD. Para criar uma Stored Procedure são escritos
dois códigos diferentes, um código é a stored procedure que será armazenada no
SGBD e o outro é o aplicativo que fará a chamada da stored procedure definida.
 36

Normalmente uma SP é utilizada quando são encontradas funções ou tarefas

que são executadas várias vezes. A seguir são expostos alguns benefícios da sua
utilização:
• melhora o desempenho em ambientes cliente/servidor, pois reduz o
tráfego de informações na rede. Com a utilização de Stored Procedure
todo o processamento é transferido ao servidor, que devolve à aplicação
somente os registros resultantes, reduzindo também a utilização de
memória e acesso a disco na estação cliente;
• o ciclo de desenvolvimento de uma aplicação é reduzido através da
reutilização de códigos. Ao colocar uma função, que é muito utilizada em
ambientes de aplicações para banco de dados, em uma stored procedure,
possibilitamos o compartilhamento deste módulo com vários usuários e
aplicações;
• facilidade de manutenção e administração. Como a Stored Procedure está
no servidor, a sua alteração é válida para todos os usuários e aplicações
que a utilizam;
• stored Procedures são mais eficientes do que comandos SQL, que
precisam ser compilados e otimizados pelo SGBD a cada execução. Esta
característica não é notável em estações que usam bancos de dados
locais, mas é bem clara quando observado um ambiente de múltiplos
bancos de dados e vários usuários concorrentes.
 37

6 RESULTADOS

A Tabela 6.1 apresenta o tempo médio que a aplicação leva para realizar a
conexão com cada banco.

Ambiente Mono-Usuário Ambiente Multi-Usuário

CATEGORIA
FIREBIRD POSTGRESQL FIREBIRD POSTGRESQL
Conexão 0.019 seg. 0.020 seg. 0.025 seg. 0.027 seg.

Tabela 6.1 – Resultado dos Testes de Conexão.

Foi observado que os dois sistemas apresentam desempenhos muito

próximos na categoria conexão. Entretanto, nos testes de inserção de 10.000
registros e 100.000 registros, o PostgreSQL mostrou resultados superiores,
apresentados na Tabela 6.2 (melhores tempos em negrito).
Os valores apresentados na tabela não indicam que o PostgreSQL obteve um
melhor tempo de resposta do que o Firebird em todas as execuções da aplicação de
inserção. Indicam que a maioria dos resultados foi favorável ao PostgreSQL. É
necessário destacar que dentre os tempos coletados houve tempos do Firebird
superiores a alguns tempos do PostgreSQL.
Isto porque, por exemplo, no teste de inserção de 10.000 registros mono-
usuário, os tempos coletados do Firebird estavam entre 14.60 e 21.08, e os tempos
do PostgreSQL estavam entre 14.29 e 15.51. Então, houve tempos do Firebird
menores que tempos do PostgreSQL, mas na média o PostgreSQL foi superior.

Ambiente Mono-Usuário Ambiente Multi-Usuário

CATEGORIA
FIREBIRD POSTGRESQL FIREBIRD POSTGRESQL
Inserção de 17.53 seg. 14.88 seg. 1.38 min. 57.33 seg.
10.000 registros
Inserção de
3.03 min. 2.31 min. 12.15 min. 9.42 min.
100.000 registros

Tabela 6.2 – Resultado dos Testes de Inserção.

 38

O tempo que cada SGBD levou para realizar a seleção de 1.000 registros em
uma base de 10.000 cadastrados e a seleção de 10.000 registros em uma base de
100.000 é mostrado na Tabela 6.3.

Ambiente Mono-Usuário Ambiente Multi-Usuário

CATEGORIA
FIREBIRD POSTGRESQL FIREBIRD POSTGRESQL
Consulta de 1.000
1.92 seg. 0.99 seg. 6.39 seg. 1.47 seg.
registros (10.000)
Consulta de 10.000
20.18 seg. 9.93 seg. 1.59 min. 23.82 seg.
registros (100.000)

Tabela 6.3 – Resultado dos Testes de Seleção.

Na categoria consulta o sistema Firebird também mostrou ser mais lento do

que o PostgreSQL. Esta diferença é perceptível principalmente no ambiente multi-
usuário na consulta de 10.000 registros. É importante relembrar que estes valores
são uma média em uma amostragem de 10 tempos coletados, mas o interessante
nesta categoria é que foi observado que mesmo o pior tempo de resposta do
PostgreSQL ainda é superior ao melhor tempo de resposta do Firebird. Por exemplo,
nos testes de consulta de 1.000 registros no ambiente mono-usuário, o maior tempo
do PostgreSQL dentre os 10 (dez) foi 1.13 segundos e o menor tempo do Firebird foi
1.44 segundos. No teste de consulta de 10.000 registro, no ambiente multi-usuário, o
maior tempo de uma estação no PostgreSQL (não a média entre as cinco) foi de 34
segundos e no Firebird o menor tempo foi de 1.24 minutos. O que permite validar
com segurança que o sistema PostgreSQL foi superior ao Firebird nos testes de
seleção.
Na Tabela 6.4 é apresentada a diferença do tempo de resposta de um
sistema utilizando stored procedure. O desempenho foi melhorado
consideravelmente, mantendo o melhor desempenho do sistema PostgreSQL.
 39

Ambiente Mono-Usuário Ambiente Multi-Usuários

CATEGORIA
FIREBIRD POSTGRESQL FIREBIRD POSTGRESQL
Inserção com
Stored Procedure 5.24 seg. 0.95 seg. 35.81 seg. 1.96 seg.
10.000 registros
Inserção com
Stored Procedure 1.49 min. 6.88 seg. 8.52 min. 58.98 seg.
100.000 registros

Tabela 6.4 – Resultado dos Testes de Inserção com Stored Procedure.

 40

7 CONCLUSÕES E TRABALHOS FUTUROS

A finalidade desta análise foi apresentar um comparativo de desempenho

entre os SGBDs PostgreSQL e Firebird na plataforma Windows 2000. Os testes
revelaram que o desempenho do PostgreSQL é superior ao do Firebird nas
operações de inserção e consulta. Particularmente nas operações de consulta, o
PostgreSQL se sobressaiu, onde foi observado que mesmo o pior tempo de
resposta do PostgreSQL ainda é superior ao melhor tempo de resposta do Firebird.
As próximas pesquisas incluem novos testes envolvendo joins entre duas ou
mais tabelas, bem como implementação de novas operações, como por exemplo
atualizações e exclusões de dados. É interessante também realizar novos testes
utilizando bases de dados com tamanhos significativos (10 Gb, 20 Gb).
Finalizando, as atividades futuras também compreendem a aplicação desta
pesquisa envolvendo outros bancos de dados livres, bem como trabalhar com banco
de dados proprietários, como o SQL Server, Oracle ou BD2. Até porque todos os
sistemas citados já dispõem de uma versão freeware para avaliação.
 41

REFERÊNCIAS BIBLIOGRÁFICAS

APACHE. "The Apache Software Foundation". Disponível em:

<http://www.apache.org/>. Acesso em: 09 de Outubro de 2006.

CAVALCANTI, E.P. “Revolução da Informação: Algumas Reflexões”. Caderno de

Pesquisa em Administração, São Paulo, V.1, Nº. 1, 1995.

DATE, C.J. “Introdução a Sistemas de Bancos de Dados”. Rio de Janeiro: Ed.

Campus, 2000.

GRAY, J. “The Benchmark Handbook for Database and Transaction Processing

Systems”. Morgan Kaufmann, 2 ed., 1993.

HUTH, G. “Um Modelo para o Gerenciamento de Banco de Dados SQL através

de Stored Procedure”. Universidade Federal de Santa Catarina, 2002.

IBPHOENIX.“Comparando a Arquitetura Classic e Superserver do Firebird”.

Equipe IBPhoenix – Tradução: Paulo Vaz, 2002. Disponível em:
<http://www.comunidade-firebird.org/>. Acesso em: 03 de Maio de 2007.

KINOSHITA, V.G. “Banco de Dados Via Web: uma Análise Comparativa”.

Universidade Federal de Lavras, 2001.

MACHADO, F. N. R. “Tecnologia e Projeto de Data Warehouse”. São Paulo:

Érica, 2004.

NETO, A.P. “PostgreSQL: Técnicas Avançadas – Versões Open Source 7.x” 2ª

ed. São Paulo: Editora Érica, 2003.

PHP. "PHP: Hipertext Preprocessor". Disponível em: <http://www.php.net/>.

Acesso em: 09 de Outubro de 2006.

PIRES, C.S.; NASCIMENTO, R.O.; SALGADO, A.C. “Comparativo de

Desempenho entre os Bancos de Dados de Código Aberto”. Universidade
Federal de Pernambuco (UFPE), 2006.

POSTGRESQL GLOBAL DEVELOPMENT GROUP. “Tutorial do PostgreSQL 8 /

Official Documentation”. Tradução: Halley Pacheco de Oliveira. Rio de Janeiro,
2005. Disponível em: <http://www.postgresql.org/>. Acesso em: 10 de Dezembro de
2006.

SILVA, F.P. “Um Benchmark para Sistemas de Gerenciamento de Workflow”.

Universidade Federal do Rio de Janeiro (UFRJ), 2004.

SVOBODOVA, L. “Computer Performance Measrement and Evaluation

Methods: Analysis and Applications”. Elsevier Scientific Publishing Company,
1976.
 42

TPC. "Transaction Processing Performance Council", 2004. Disponível em:

<http://www.tpc.org/>. Acesso em: 09 de Fevereiro de 2007.

TPC-APP. “TPC Benchmark App (Application Server) Especification Version

1.1.1”. Disponível em <http://www.tpc.org/tpc_app/spec/TPC-App_V1.1.1.pdf>.
Acesso em: 09 de Fevereiro de 2007.

TURBYFILL, C.; ORJI, C.; BITTON, D. “AS3AP: An ANSI SQL Standard Scalable
and Portable Benchmark for Relational Database Systems”. The Benchmark
Handbook for Database and Transaction Processing, Chapter 4. Morgan Kaufman,
1992.