Firebird – SuperServer, ClassicServer ou SuperClassic?

Uma das decisões mais importantes na implantação de um servidor Firebird é a escolha do tipo de servidor. A escolha é feita na tela do instalador.

Se já é difícil fazer uma escolha bem informada hoje, espere até o lançamento do Firebird 2.5. Serão 3 opções. SuperServer, ClassicServer e SuperClassic.

As grandes diferenças entre eles estão no cache de páginas e no modo como o servidor gerencia o processo e os threads que executam seus comandos.

SuperServer

No Super Server existe apenas um cache de páginas que é compartilhado por todas as conexões.

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 se beneficiam de um cache grande e bem preenchido.

Por exemplo, quando o cliente A executa:

SELECT NOME FROM CLIENTES WHERE CODIGO = 1

algumas páginas relacionadas a tabela CLIENTES e ao índice da chave 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:

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 delas. 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.

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:

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.

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

 

 

Para efetuar as configurações necessárias para a utilização do Classic Server e SuperClassic com melhor performance, será necessário aplicar os parâmetros abaixo de acordo com cada ambiente. 

 

Quando instalado em um servidor dedicado, com um bom processador e memória, é possível fazer algumas configurações no Firebird para melhorar o seu desempenho.O arquivo se localiza na pasta (por padrão) C:/Program Files/Firebird/2.5/firebird.conf, dentro dele há várias configurações dos parâmetros com suas explicações, porém as linhas destes parâmetros estão com o simbolo de # no inicio das linhas , para deixar as mesmas comentadas e o Firebird utilizar as configurações padrões.Para a correta configuração, deve-se colocar estas linhas abaixo de acordo com cada ambiente , sem o simbolo de #.

 

Configurações

• [SuperServer] Configuração para servidor com processador dual-core, e pelo menos 4GB memória:

  DefaultDbCachePages = 4096
  FileSystemCacheThreshold = 67108864
  FileSystemCacheSize = 70
  CpuAffinityMask = 3

  [SuperServer] Configuração para servidor com processador dual-core, e pelo menos 8GB memória:

  DefaultDbCachePages = 8192
  FileSystemCacheThreshold = 134217728
  FileSystemCacheSize = 70
  CpuAffinityMask = 3

  [SuperServer] Configuração para servidor com processador quad-core, e acima de 8GB memória:

  DefaultDbCachePages = 16384
  FileSystemCacheThreshold = 268435456
  FileSystemCacheSize = 80
  CpuAffinityMask = 3

  [SuperClassic] Utilização em ambientes com muitos usuários e processos, configuração para servidor com processador dual-core, e pelo menos 8GB memória:

  DefaultDbCachePages = 384
  TempBlockSize = 2048576
  TempCacheLimit = 567108864
  LockMemSize = 5048576
  LockHashSlots = 30011

  
  

  OBS: Importante sempre fazer um backup do arquivo Firebird.conf antes de realizar este procedimento, pois a configuração incorreta do mesmo pode causar o não funcionamento de suas aplicações.