Вы находитесь на странице: 1из 6

Comparando a arquitetura Classic e

SuperServer do Firebird
Conheça um pouco mais sobre as arquiteturas Classic e SuperServer do Firebird
Comparando a arquitetura Classic e Superserver do Firebird

A arquitetura SuperServer

Mais recente que a versão Classic, é uma implementação multi-clientes e multitarefas.

A arquitetura Superserver pode servir muitos clientes ao mesmo tempo usando o recurso de
multi-processamento ou "threads", ao invés de processos separados para cada cliente.

Threads múltiplas compartilham um único processo de servidor. Os benefícios desta


arquitetura incluem:

- Havendo um único processo de servidor, elimina-se os gargalos resultantes do


gerenciamento ao acesso compartilhado de páginas do banco de dados e reduz a
sobrecarga requerida pela inicialização de novos processos e consultas.

- Melhora a performance da interação das mensagens porque uma chamada compartilhada


à uma biblioteca é sempre mais rápida que os processos de comunicação entre os processos
de cliente e do servidor.

- Melhora a integridade do banco de dados, porque somente um processo de servidor


acessa o banco de dados, muito melhor que um processo para cada cliente.

Toda a funcionalidade do motor de banco de dados é encapsulada em um subsistema


unificado, protegido e isolado de um erro da aplicação do usuário.

- Permite o acesso às estatísticas do banco de dados e informações sobre os usuários que


ferramentas podem utilizar para monitorar performance ou executar tarefas
administrativas.

- Tem uma relação custo-benefício melhor que a arquitetura Classic. Todos os sistemas
operacionais possuem um limite no número de processos que podem ser executados
concorrentemente. O SuperServer permite que um número fixo de tarefas possam ser
multiplexadas através de um número potencialmente grande de conexões concorrentes ao
banco de dados. Desde que estas tarefas não sejam muito pesadas ou dedicadas à uma
conexão específica, o SuperServer pode suportar um grande número de usuários com um
uso mínimo de recursos do sistema.

A arquitetura Classic

Desenvolvida desde a versão 4 do Interbase, é baseada em processos. Para cada conexão é


iniciado um processo de servidor separado para execução do motor do banco de dados, e
cada processo tem um cache de banco de dados dedicado.

Os processos disputam entre si o acesso ao banco de dados, portanto um subsistema de


gerenciamento de travamentos é requerido para arbitrar e sincronizar o acesso concorrente
à páginas do banco de dados pelos processos.

Funcionamento da arquitetura Classic

O servidor Classic, roda sob demanda das conexões. Quando um cliente tenta conectar-se à
um banco de dados Firebird, uma instância do executável gds_inet_server é executada e
permanece dedicada à conexão do cliente enquanto esta estiver ativa.

O inicializador do gds_inet_server é o inetd, o processo gerenciador de serviços do Unix. Ele


possui um arquivo de configuração o /etc/inetd.conf, que associa serviços com os
executáveis que irão receber a conexão. Quando o inetd recebe uma requisição de conexão
à um serviço disponível, ele busca o programa apropriado no arquivo de configuração,
executa-o, e transfere a conexão de rede ao serviço. Quando um cliente solicita a

-2-
Comparando a arquitetura Classic e Superserver do Firebird

desconexão, o gds_inet_server fecha a conexão ao banco de dados e outros arquivos, e


então sai. Quando não há clientes conectados à um banco de dados, não devem haver
instâncias do gds_inet_server rodando.

Gerenciamento de Travamentos

O gerenciamento de travamentos é cuidado por um outro processo, o gds_lock_mgr. Este


programa é iniciado quando um segundo cliente conecta-se ao mesmo banco de dados. O
trabalho do gerenciador de travamentos é servir (metaforicamente) como um policial de
trânsito. Ele garante o travamento de recursos do banco de dados para os clientes.

Isto também requer que os clientes notifiquem os travamentos de um recurso quando este
recurso é solicitado por outros clientes. O gds_lock_mgr permanece rodando mesmo depois
que o último cliente de desconecta. Na próxima vez que um cliente conectar-se, isto pode
evitar a sobrecarga de inicialização do gerenciador de processos.

Uso de sinalizadores Posix

O processo gds_lock_mgr comunica-se com cada processo cliente utilizando uma área de
memória compartilhada, através de um mecanismo de sinalização usando os sinais POSIX
SIGUSR1 e SIGUSR2. Os sinais são únicos nas rotinas de manipulação em libgdslib.a, e por
esta razão as aplicações dos usuários não devem manipular os sinais ou modificar a
máscara dos sinais.

Aplicações que necessitem o uso de sinais POSIX devem ser compiladas com uma biblioteca
alternativa do Firebird, a libgds.a. Esta bilblioteca tem funcões idênticas à libgdslib.a, mas
ela manipula os sinais enviados pelo gerenciador de travamentos em um processo-filho
chamado gds_pipe. Todas as aplicações clientes compiladas com a libgds.a rodam
automaticamente com este processo-filho. Não são necessárias modificações no código da
aplicação, somente uma opção de linkagem diferente.

Uso de recursos do sistema

Cada instância do gds_inet_server mantém um cache das páginas do banco de dados em


seu espaço de memória, o que pode resultar em duplicação dos dados armazenados no
sistema. Enquanto o uso de recursos por clientes é maior que na versão Superserver, a
versão Classic usa menos recursos de sistema quando o número de conexões concorrentes
é baixo.

Método de acesso local

A arquitetura Classic permite que processos façam acesso de I/O diretamente aos arquivos
de bancos de dados, enquanto a arquitetura SuperServer requer que as aplicações solicitem
ao servidor operações de I/O por um proxy, usando um método de rede. O método de
acesso local é mais rápido que o acesso por rede, mas só é utilizável por aplicações que
rodem na mesma máquina do banco de dados.

Monitorando conexões ao banco de dados

A chamada de informações sobre as conexões ao banco de dados sempre retornam


exatamente uma conexão no servidor Classic, não importa quantos clientes estejam
conecatados a bancos de dados naquele servidor. A razão disto é que cada conexão de
cliente tem seu próprio processo gds_inet_server no servidor, e cada instância deste
programa conhece somente a sua própria conexão.

Somente o SuperServer faz com que o processo de servidor tenha a capacidade de


reconhecer todos os clientes conectados no servidor.

-3-
Comparando a arquitetura Classic e Superserver do Firebird

Segurança

Em função da versão Classic poder trabalhar com uma mistura de clientes locais e remotos
como usuários diferentes, os executáveis gds_inet_server e gds_lock_mgr devem rodar
como o super-usuário root. Os processos devem rodar com uma identidade do root para
definir sua efetivas identidades para as identidades de clientes.

O gerenciador de travamentos precisa ter privilégios de super-usuário para enviar sinais aos
processos.

Em alguns ambientes, a presença de executávies com bits setuid ligados podem afetar a
segurança. Mesmo assim, não mude a configuração de execução do servidor Firebird. A uso
do super-usuário para bits setuid do servidor Classic é importante para o seu
funcionamento.

Como as aplicações podem rodar com qualquer número de uid, os arquivos de banco de
dados devem conceder permissão de escrita para todos os uids que acessam os bancos de
dados. Para simplificar a manutenção, os arquivos de bancos de dados são criados com
permissão de escrita por todo mundo. Com cuidado, você pode restringir estas permissões,
então os arquivos de bancos de dados podem ser protegidos de danos acidentais ou
deliberados. Tenha certeza que você conhece e entende de permissões de acesso à arquivos
antes de tentar modificar isto, porque todos os clientes locais e remotos precisam de acesso
de escrita ao banco de dados, a menos que se deseje apenas que leiam dados.

Comparando Classic e SuperServer

Funcionamento do SuperServer

Um servidor SuperServer roda como um único processo, uma única carga do executável
ibserver. Ele é iniciado uma vez apenas pelo administrador do sistema ou por um script de
inicialização. Este processo está sempre rodando, esperando por um pedido de conexão.

Quando não há nenhum cliente conectado a um banco de dados no servidor o ibserver


continua rodando silenciosamente.

O processo do SuperServer não depende do inetd; ele espera por uma requisição de
conexão ao serviço gds_db por si mesmo.

O processo do SuperServer é uma aplicação multi-thread (multi-processada). Diferentes


threads com processos são dedicadas à diferentes processos.

Normalmente, uma thread espera por uma requisição de conexão na porta do serviço
gds_db.

Outras threads são análogas aos processos individuais de gds_inet_server no modelo


clássico, servindo consultas de clientes. Outra thread serve ao gerenciador de travamentos,
substituindo o processo gds_lock_mgr do modelo Classic.

Gerenciamento de Travamentos

O gerenciador de travamentos no SuperServer é implementado como uma thread no


executável ibserver. Por isto o Firebird não utiliza o processo gds_lock_mgr.

Assim sendo, sinalizadores POSIX não são utilizados pela thread do gerenciador de
travamentos no SuperServer; e sim mecanismos de comunicação interthread.

-4-
Comparando a arquitetura Classic e Superserver do Firebird

Uso de recursos do sistema

O modelo SuperServer tem menos sobrecarga e usa menos recursos por conexão de
clientes que o modelo Classic. O Superserver usa um único espaço de cache para todas as
ligações de clientes, permitindo um uso mais eficiente da memória cache.

Por estas e outras razões, o modelo SuperServer têm demonstrado uma habilidade de
servir de forma mais eficiente um grande número de clientes concorrentes.

Servidores multi-threads e UDF's

As UDF's (User-Defined Functions) são bibliotecas de funções que você pode adicionar para
extender o conjunto de funções que o servidor Firebird suporta. As funções em sua bibliteca
UDF são executadas no contexto do processo do servidor.

Através da implementação de threads do SuperServer, existem questões com UDFs que


requerem que você escreva as funções da UDF com mais cuidado do que no modelo Classic.

Você precisa projetar UDF's para o SuperServer como funções thread-safe. Você não pode
utilizar variáveis globais em sua UDF, porque dois clientes rodando a UDF simultâneamente,
vão conflitar no seu uso com variáveis globais. Não utilize variáveis as globais da thread
para simular variáveis globais. O modelo SuperServer implementa uma espécie mecanismo
de armazenamento de threads, para compartilhar threads através de todas as conexões de
clientes. Isto é como se um cliente executar uma UDF duas vezes, que cada execução não
seja executada no contexto da mesma thread. Isto significa que você não pode depender de
variáveis locais da thread para guardar valores de uma execução da UDF para outra.

UDFs que aloquem memória dinâmicamente correm o risco de criar um espaço perdido na
memória. Imaginando-se que o SuperServer irá permanecer no ar e rodando
indefinidamente, não somente durante o tempo de vida da conexão do cliente, espaços de
memória perdidos podem ser mais nocivos ao SuperServer do que o modelo Classic.

Se suas UDFs retornam objetos alocados dinamicamente, então você deve utilizar a função
malloc() para alocar memória para estes objetos (na plataforma Windows, você deve utilizar
ib_util_malloc() ou o malloc() que é parte da biblioteca de runtime do Microsoft Visual
C++). Não use new ou globalalloc() ou a função malloc() do compilador da Borland.
Finalmente, estas funções devem ser declaradas nos bancos de dados com a opção FREE_IT
da instrução DECLARE EXTERNAL FUNCTION.

Em contraste, no modelo Clássico, por haver um processo separado para cada conexão de
cliente, as UDF's estão garantidas que não conflitarão. Variáveis globais são seguras para
utilização. Também espaços perdidos de memória não são perigosos, porque qualquer
espaço perdido é liberado quando o cliente se desconecta.

Portanto a recomendação é que o uso de UDF's para o SuperServer deve ser mais restrito
do que o uso no modelo Classic. Se você utiliza o modelo Classic, certifique-se de que suas
UDF's não oferecem risco de uso no modelo SuperServer antes de efetuar o upgrade. Se
estas forem construídas dentro dos padrões estabelecidos, não oferecerão riscos, caso
contrário deverão ser reescritas.

Segurança

O modelo SuperServer pode ser configurado para rodar com uma uid não-root, para melhor
segurança. Você pode ainda restringir as permissões nos arquivos de banco de dados
somente para a uid do servidor Firebird, para acessar o banco de dados.

-5-
Comparando a arquitetura Classic e Superserver do Firebird

Porque dois modelos?

O modelo Classic é anterior ao SuperServer, e o SuperServer é o futuro do Firebird.

A configuração Classic é utilizada em sistemas operacionais que não dispõe de tecnologia


para executar aplicações multi-thread, requerida pelo SuperServer. É possivel utilizar o
modelo Classic para plataformas que suportam esta tecnologia, exceto a plataforma
Windows, que dispõe apenas do modelo SuperServer.

O SuperServer tem a capacidade de atender as demandas de um sistema multiusuário em


expansão, mantendo uma boa performance e eficiência.

O modelo SuperServer foi implementado em todas as plataformas que suportam sua


tecnologia.

É a intenção que o SuperServer seja a direção futura do Firebird para todas plataformas.

Fonte.: http://www.ibphoenix.com

-6-

Вам также может понравиться