Neste artigo apresento as diferenças entre as arquiteturas de servidor Firebird, são elas SuperServer, ClassicServer e a novidade para a próxima versão 3.0 a SuperClassic, (disponível na versão 2.5 alpha http://www.firebirdsql.org/index.php?op=files&id=fb250_alpha01), basicamente as diferenças entre elas 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 SuperServer 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 à 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.
O SuperServer sofre de problemas de escalabilidade. Se a instalação for num computador com mais de uma CPU 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 não é a melhor opção.

ClassicServer

No ClassicServer 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.

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. Sendo 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 para 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 no exemplo ao lado: Firebird 2.5 Alpha  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. O SuperClassic utiliza um único processo com cache dedicado.

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.