Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
5Activity
0 of .
Results for:
No results containing your search query
P. 1
Comparando a arquitetura Classic e Super Server do Firebird

Comparando a arquitetura Classic e Super Server do Firebird

Ratings: (0)|Views: 612|Likes:
Conheça um pouco mais sobre as arquiteturas Classic e SuperServer do Firebird
Conheça um pouco mais sobre as arquiteturas Classic e SuperServer do Firebird

More info:

Published by: John Klaus Kanenberg on Jan 25, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF or read online from Scribd
See more
See less

09/15/2010

pdf

 
Comparando a arquitetura Classic eSuperServer do Firebird
Conheça um pouco mais sobre as arquiteturas Classic e SuperServer do Firebird
 
Comparando a arquitetura Classic e Superserver do Firebird
- 2 -
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 demulti-processamento ou "threads", ao invés de processos separados para cada cliente.Threads múltiplas compartilham um único processo de servidor. Os benefícios destaarquitetura incluem:- Havendo um único processo de servidor, elimina-se os gargalos resultantes dogerenciamento ao acesso compartilhado de páginas do banco de dados e reduz asobrecarga 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 processosde cliente e do servidor.- Melhora a integridade do banco de dados, porque somente um processo de servidoracessa o banco de dados, muito melhor que um processo para cada cliente.Toda a funcionalidade do motor de banco de dados é encapsulada em um subsistemaunificado, 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 queferramentas podem utilizar para monitorar performance ou executar tarefasadministrativas.- Tem uma relação custo-benefício melhor que a arquitetura Classic. Todos os sistemasoperacionais possuem um limite no número de processos que podem ser executadosconcorrentemente. O SuperServer permite que um número fixo de tarefas possam sermultiplexadas através de um número potencialmente grande de conexões concorrentes aobanco de dados. Desde que estas tarefas não sejam muito pesadas ou dedicadas à umaconexão específica, o SuperServer pode suportar um grande número de usuários com umuso 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, ecada processo tem um cache de banco de dados dedicado.Os processos disputam entre si o acesso ao banco de dados, portanto um subsistema degerenciamento 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 epermanece 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. Elepossui um arquivo de configuração o /etc/inetd.conf, que associa serviços com osexecutá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
 
Comparando a arquitetura Classic e Superserver do Firebird
- 3 -
desconexão, o gds_inet_server fecha a conexão ao banco de dados e outros arquivos, eentão sai. Quando não há clientes conectados à um banco de dados, não devem haverinstâncias do gds_inet_server rodando.
Gerenciamento de Travamentos
O gerenciamento de travamentos é cuidado por um outro processo, o gds_lock_mgr. Esteprograma é iniciado quando um segundo cliente conecta-se ao mesmo banco de dados. Otrabalho do gerenciador de travamentos é servir (metaforicamente) como um policial detrâ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 esterecurso é solicitado por outros clientes. O gds_lock_mgr permanece rodando mesmo depoisque o último cliente de desconecta. Na próxima vez que um cliente conectar-se, isto podeevitar 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 dememória compartilhada, através de um mecanismo de sinalização usando os sinais POSIXSIGUSR1 e SIGUSR2. Os sinais são únicos nas rotinas de manipulação em libgdslib.a, e poresta razão as aplicações dos usuários não devem manipular os sinais ou modificar amáscara dos sinais.Aplicações que necessitem o uso de sinais POSIX devem ser compiladas com uma bibliotecaalternativa do Firebird, a libgds.a. Esta bilblioteca tem funcões idênticas à libgdslib.a, masela manipula os sinais enviados pelo gerenciador de travamentos em um processo-filhochamado gds_pipe. Todas as aplicações clientes compiladas com a libgds.a rodamautomaticamente com este processo-filho. Não são necessárias modificações no código daaplicaçã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 emseu espaço de memória, o que pode resultar em duplicação dos dados armazenados nosistema. Enquanto o uso de recursos por clientes é maior que na versão Superserver, aversã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 arquivosde bancos de dados, enquanto a arquitetura SuperServer requer que as aplicações solicitemao servidor operações de I/O por um proxy, usando um método de rede. O método deacesso local é mais rápido que o acesso por rede, mas só é utilizável por aplicações querodem 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 retornamexatamente uma conexão no servidor Classic, não importa quantos clientes estejamconecatados a bancos de dados naquele servidor. A razão disto é que cada conexão decliente tem seu próprio processo gds_inet_server no servidor, e cada instância desteprograma conhece somente a sua própria conexão.Somente o SuperServer faz com que o processo de servidor tenha a capacidade dereconhecer todos os clientes conectados no servidor.

Activity (5)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Saulo Mendes liked this
ravascon liked this
gilberthgfs liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->