05/10/2015 Firebird 

– SuperServer, ClassicServer ou SuperClassic? | Sinática | BLOG

HOME   MONITOR   BLOG   CONTATO BUSCA

Firebird – SuperServer, ClassicServer ou SuperClassic?

categorias
Uma das decisões mais Delphi (1)
importantes na implantação de um Eventos (8)
servidor Firebird é a escolha do Firebird (17)
tipo de servidor. A escolha é feita Negócios (4)
na tela do instalador. Sinática (22)

Se já é difícil fazer uma escolha

arquivos
bem informada hoje, espere até o
lançamento do Firebird 2.5. Serão maio 2010

3 opções. SuperServer, março 2010

setembro 2009
ClassicServer e SuperClassic.
agosto 2009
As grandes diferenças entre eles estão no cache de páginas e no modo junho 2009
como o servidor gerencia o processo e os threads que executam seus maio 2009

comandos. abril 2009

fevereiro 2009
janeiro 2009
dezembro 2008
SuperServer novembro 2008
outubro 2008
No Super Server existe apenas um cache de páginas que é compartilhado
setembro 2008
por todas as conexões.
agosto 2008
julho 2008
Por ser compartilhado, este cache é muito eficiente. Quando vários
clientes acessam as mesmas áreas do banco de dados ou quando
algumas tabelas são muito mais acessadas que outras, todos os clientes links
se beneficiam de um cache grande e bem preenchido. Artigos Firebird
Entre em contato
Por exemplo, quando o cliente A executa: Recomendados
Sobre este Blog
SELECT NOME FROM CLIENTES WHERE CODIGO = 1;
Assinar
algumas páginas relacionadas a tabela CLIENTES e ao índice da chave
Twitter
primária CODIGO são carregados para o cache.

Quando o cliente B executa:

SELECT NOME, ENDERECO, TELEFONE  FROM CLIENTES WHERE CODIGO = 2;

ele se beneficia do cache compartilhado porque as páginas que este

comando precisa já estão no cache.

Note também que existe apenas um único processo onde todos os

clientes se conectam.

Veja no diagrama:

http://www.sinatica.com/blog/br/index.php/artigos/firebird­superserver­classicserver­ou­superclassic 1/5
05/10/2015 Firebird – SuperServer, ClassicServer ou SuperClassic? | Sinática | BLOG

O SuperServer sofre de problemas de escalabilidade. Se você instalá-lo

num computador com mais de uma CPU (o que é bem provável hoje em
dia) ele vai usar apenas uma delas1. Isto não é problema para instalações
pequenas ou ambientes onde o servidor terá outras atividades além do
banco de dados.

Por exemplo, você tem um servidor dual-core e quer usá-lo como

servidor de arquivos, web, impressão e banco de dados. Não é problema
que o Firebird use apenas uma CPU porque o servidor terá outras
atividades para ocupar a outra CPU. E você ainda terá o benefício de usar
um banco de dados leve e ágil, que consome poucos recursos do
servidor.

Mas para operações grandes, em que você quer que o banco de dados
aproveite cada ciclo das CPUs do servidor, o SuperServer pode ser
frustrante.

1 Exceto se você tiver mais de um banco de dados. A partir do Firebird 2.5, o Superserver
consegue usar mais de uma CPU desta maneira. Uma para cada banco de dados. Se você tiver
apenas um banco de dados o limite ainda se aplica.

ClassicServer
No Classic, cada cliente tem um cache próprio e está conectado a um
processo dedicado.

O cache dedicado é muito menos eficiente. Se dois clientes acessam a

mesma área do banco de dados, esta área será copiada no cache de cada
um deles. Usando o exemplo anterior, quando o cliente B executasse seu
comando, ele não teria o benefício de um cache já preenchido e o Firebird
precisaria acessar o disco novamente para responder.

Além do mais, a sincronização entre os caches é feita através do disco.

Isto aumenta consideravelmente o custo de I/O para ambientes de alta
concorrência.

Veja no diagrama:

http://www.sinatica.com/blog/br/index.php/artigos/firebird­superserver­classicserver­ou­superclassic 2/5
05/10/2015 Firebird – SuperServer, ClassicServer ou SuperClassic? | Sinática | BLOG

Um grande benefício deste modelo é a resiliência oferecida pelos

múltiplos processos. Se um deles tiver problemas, apenas o cliente
conectado a ele será desconectado. Todo o restante do banco de dados
continua funcionando normalmente.

O outro grande benefício é a escalabilidade. Acredito que esta

característica seja a responsável por boa parte das instalações do
ClassicServer. Mesmo em casos onde o cache dedicado produz resultados
inferiores ao cache compartilhado do Superserver, a escalabilidade do
ClassicServer compensa. Basta adicionar mais hardware e pronto, seu
servidor fica mais rápido.

Mas esta escalabilidade não vem de graça. Imagine que você tem 200
clientes simultâneos. São 201 processos, um para cada cliente e mais um
para ficar ouvindo novas conexões. Seu sistema operacional deve
gerenciar todos estes processos e mantê-los em sincronia. Eles
consomem muitos recursos de kernel e isto significa que ele pode ser
relativamente lento.

Veja neste exemplo: Firebird 2.5 Alpha 1 Classic com 7 clientes

conectados. São 8 processos, 18 threads, 1050 identificadores.

SuperClassic
a partir do Firebird 2.5

A equipe de desenvolvimento decidiu usar o Firebird Classic Server como

base para construir o Firebird 3.0, que será totalmente compatível com
SMP. O SuperClassic é o primeiro passo nessa direção. É uma evolução do
Classic Server que resolve o maior problema que o Classic Server tem:
Todos aqueles processos o deixam lento e tornam a manutenção mais
difícil.

Bem-vindo ao SuperClassic: Um único processo com cache dedicado.

http://www.sinatica.com/blog/br/index.php/artigos/firebird­superserver­classicserver­ou­superclassic 3/5
05/10/2015 Firebird – SuperServer, ClassicServer ou SuperClassic? | Sinática | BLOG

Olhando assim e levando em consideração o nome, parece um híbrido

entre o Classic e o Super, mas não é. O que fizeram foi encapsular todos
aqueles processos em threads. Agora cada cliente tem um thread
dedicado dentro de um único processo.

Criar centenas de threads é muito mais barato que criar centenas de

processos e não existe perda de escalabilidade. A sincronização entre os
caches pode ser feita diretamente em memória, o que reduz o custo de
I/O. E outros controles que antes eram inter-processo agora são inter-
thread, muito mais rápidos.

Veja exemplo comparável ao Classic: Firebird 2.5 Alpha 1 SuperClassic

com 7 clientes conectados, 1 processo, 6 threads, 172 identificadores.

Conclusão
Esta compilação dos casos mais comuns de uso é uma sugestão e serve
apenas como guia, um ponto inicial na sua  escolha. A sua instalação
pode ter detalhes próprios que não foram abordados aqui.

SuperServer

Bases de dados pequenas ou pouco acessadas

Servidores pequenos
Ambientes onde o cache compartilhado é mais vantajoso que a
escalabilidade do SuperClassic

ClassicServer

Ambientes onde a estabilidade é a maior preocupação

Servidores multi-processados
Grandes bases de dados com centenas de usuários

SuperClassic

Servidores multi-processados
Grandes bases de dados com centenas de usuários
Ambientes onde o cache dedicado é mais vantajoso que o cache
compartilhado do SuperServer
Ambientes onde o ClassicServer já não consegue escalar

 
http://www.sinatica.com/blog/br/index.php/artigos/firebird­superserver­classicserver­ou­superclassic 4/5
05/10/2015 Firebird – SuperServer, ClassicServer ou SuperClassic? | Sinática | BLOG

mais artigos Firebird

Blog Sinática

Autor
Meu nome é Douglas Tosi. Eu sou a pessoa a frente da Sinática, uma
empresa criada para tornar o seu software mais eficiente.
Nosso primeiro produto, Sinática Monitor for Firebird, te ajuda a otimizar
bases de dados Firebird SQL.

©2008, 2009 SINÁTICA. Todos os direitos reservados

http://www.sinatica.com/blog/br/index.php/artigos/firebird­superserver­classicserver­ou­superclassic 5/5