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.