Академический Документы
Профессиональный Документы
Культура Документы
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
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.
- 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
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.
-2-
Comparando a arquitetura Classic e Superserver do Firebird
Gerenciamento de Travamentos
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.
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.
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.
-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.
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.
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.
Normalmente, uma thread espera por uma requisição de conexão na porta do serviço
gds_db.
Gerenciamento de Travamentos
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
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.
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.
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
É a intenção que o SuperServer seja a direção futura do Firebird para todas plataformas.
Fonte.: http://www.ibphoenix.com
-6-