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 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:
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
