• Like
  • Save
Cflp t017
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
133
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Comparando a arquitetura Classic e Superserver do Firebird Autor: Equipe IBPhoenix Tradução/Adaptação: Paulo VazA arquitetura SuperServer Mais recente que a versão Classic, é uma implementação multi-clientes e multi-tarefas. A arquitetura Superserver pode servir muitos clientes ao mesmo tempo usando orecurso de multi-processamento ou "threads", ao invés de processos separados paracada cliente. Threads múltiplas compartilham um único processo de servidor. Os benefíciosdesta arquitetura 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 chamadacompartilhada à uma biblioteca é sempre mais rápida que os processos decomunicação entre os processos de cliente e do servidor. - Melhora a integridade do banco de dados, porque somente um processo deservidor acessa o banco de dados, muito melhor que um processo para cada cliente.Toda a funcionalidade do motor de banco de dados é encapsulada em umsubsistema 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 osusuários que ferramentas podem utilizar para monitorar performance ou executartarefas administrativas. - Tem uma relação custo-benefício melhor que a arquitetura Classic. Todos ossistemas operacionais possuem um limite no número de processos que podem serexecutados concorrentemente. O SuperServer permite que um número fixo detarefas possam ser multiplexadas através de um número potencialmente grande deconexões concorrentes ao banco de dados. Desde que estas tarefas não sejammuito pesadas ou dedicadas à uma conexão específica, o SuperServer podesuportar um grande número de usuários com um uso mínimo de recursos dosistema.A arquitetura Classic Desenvolvida desde a versão 4 do Interbase, é baseada em processos. Paracada conexão é iniciado um processo de servidor separado para execução do motordo 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 umsubsistema de gerenciamento de travamentos é requerido para arbitrar e sincronizaro 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 tentaconectar-se à um banco de dados Firebird, uma instância do executávelgds_inet_server é executada e permanece dedicada à conexão do cliente enquantoesta estiver ativa. O inicializador do gds_inet_server é o inetd, o processo gerenciador de serviçosdo Unix. Ele possui um arquivo de configuração o /etc/inetd.conf, que associaserviços com os executáveis que irão receber a conexão. Quando o inetd recebe
  • 2. uma requisição de conexão à um serviço disponível, ele busca o programaapropriado no arquivo de configuração, executa-o, e transfere a conexão de rede aoserviço. Quando um cliente solicita a desconexão, o gds_inet_server fecha aconexão ao banco de dados e outros arquivos, e então sai. Quando não há clientesconectados à um banco de dados, não devem haver instâncias do gds_inet_serverrodando. Gerenciamento de Travamentos O gerenciamento de travamentos é cuidado por um outro processo, ogds_lock_mgr. Este programa é iniciado quando um segundo cliente conecta-se aomesmo banco de dados. O trabalho do gerenciador de travamentos é servir(metaforicamente) como um policial de trânsito. Ele garante o travamento derecursos do banco de dados para os clientes. Isto também requer que os clientes notifiquem os travamentos de um recursoquando este recurso é solicitado por outros clientes. O gds_lock_mgr permanecerodando mesmo depois que o último cliente de desconecta. Na próxima vez que umcliente conectar-se, isto pode evitar a sobrecarga de inicialização do gerenciador deprocessos. 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 usandoos sinais POSIX SIGUSR1 e SIGUSR2. Os sinais são únicos nas rotinas demanipulação em libgdslib.a, e por esta razão as aplicações dos usuários não devemmanipular os sinais ou modificar a máscara dos sinais. Aplicações que necessitem o uso de sinais POSIX devem ser compiladas comuma biblioteca alternativa do Firebird, a libgds.a. Esta bilblioteca tem funcõesidênticas à libgdslib.a, mas ela manipula os sinais enviados pelo gerenciador detravamentos em um processo-filho chamado gds_pipe. Todas as aplicações clientescompiladas com a libgds.a rodam automaticamente com este processo-filho. Nãosão necessárias modificações no código da aplicação, somente uma opção delinkagem diferente. Uso de recursos do sistema Cada instância do gds_inet_server mantém um cache das páginas do banco dedados em seu espaço de memória, o que pode resultar em duplicação dos dadosarmazenados no sistema. Enquanto o uso de recursos por clientes é maior que naversão Superserver, a versão Classic usa menos recursos de sistema quando onúmero de conexões concorrentes é baixo. Método de acesso local A arquitetura Classic permite que processos façam acesso de I/O diretamente aosarquivos de bancos de dados, enquanto a arquitetura SuperServer requer que asaplicações solicitem ao servidor operações de I/O por um proxy, usando um métodode 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. Monitorando conexões ao banco de dados A chamada de informações sobre as conexões ao banco de dados sempreretornam exatamente uma conexão no servidor Classic, não importa quantosclientes 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 capacidadede reconhecer todos os clientes conectados no servidor. Segurança Em função da versão Classic poder trabalhar com uma mistura de clientes locaise remotos como usuários diferentes, os executáveis gds_inet_server egds_lock_mgr devem rodar como o super-usuário root. Os processos devem rodarcom uma identidade do root para definir sua efetivas identidades para as identidadesde clientes. O gerenciador de travamentos precisa ter privilégios de super-usuário para enviarsinais aos processos. Em alguns ambientes, a presença de executávies com bits setuid ligados podemafetar a segurança. Mesmo assim, não mude a configuração de execução doservidor 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 debanco de dados devem conceder permissão de escrita para todos os uids queacessam os bancos de dados. Para simplificar a manutenção, os arquivos debancos de dados são criados com permissão de escrita por todo mundo. Comcuidado, você pode restringir estas permissões, então os arquivos de bancos dedados podem ser protegidos de danos acidentais ou deliberados. Tenha certeza quevocê conhece e entende de permissões de acesso à arquivos antes de tentarmodificar isto, porque todos os clientes locais e remotos precisam de acesso deescrita 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 doexecutável ibserver. Ele é iniciado uma vez apenas pelo administrador do sistema oupor um script de inicialização. Este processo está sempre rodando, esperando porum pedido de conexão. Quando não há nenhum cliente conectado a um banco dedados no servidor o ibserver continua rodando silenciosamente. O processo do SuperServer não depende do inetd; ele espera por uma requisiçãode 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 doserviço gds_db. Outras threads são análogas aos processos individuais de gds_inet_server nomodelo clássico, servindo consultas de clientes. Outra thread serve ao gerenciadorde travamentos, substituindo o processo gds_lock_mgr do modelo Classic.
  • 4. Gerenciamento de Travamentos O gerenciador de travamentos no SuperServer é implementado como uma threadno 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 detravamentos no SuperServer; e sim mecanismos de comunicação interthread. Uso de recursos do sistema O modelo SuperServer tem menos sobrecarga e usa menos recursos porconexão de clientes que o modelo Classic. O Superserver usa um único espaço decache para todas as ligações de clientes, permitindo um uso mais eficiente damemória cache. Por estas e outras razões, o modelo SuperServer têm demonstrado umahabilidade de servir de forma mais eficiente um grande número de clientesconcorrentes. Servidores multi-threads e UDFs As UDFs (User-Defined Functions) são bibliotecas de funções que você podeadicionar para extender o conjunto de funções que o servidor Firebird suporta. Asfunçõ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 UDFsque requerem que você escreva as funções da UDF com mais cuidado do que nomodelo Classic. Você precisa projetar UDFs para o SuperServer como funções thread-safe. Vocênão pode utilizar variáveis globais em sua UDF, porque dois clientes rodando a UDFsimultâneamente, vão conflitar no seu uso com variáveis globais. Não utilizevariáveis as globais da thread para simular variáveis globais. O modelo SuperServerimplementa uma espécie mecanismo de armazenamento de threads, paracompartilhar threads através de todas as conexões de clientes. Isto é como se umcliente executar uma UDF duas vezes, que cada execução não seja executada nocontexto da mesma thread. Isto significa que você não pode depender de variáveislocais 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çoperdido na memória. Imaginando-se que o SuperServer irá permanecer no ar erodando indefinidamente, não somente durante o tempo de vida da conexão docliente, espaços de memória perdidos podem ser mais nocivos ao SuperServer doque o modelo Classic. Se suas UDFs retornam objetos alocados dinamicamente, então você deveutilizar a função malloc() para alocar memória para estes objetos (na plataformaWindows, você deve utilizar ib_util_malloc() ou o malloc() que é parte da bibliotecade runtime do Microsoft Visual C++). Não use new ou globalalloc() ou a funçãomalloc() do compilador da Borland. Finalmente, estas funções devem ser declaradasnos bancos de dados com a opção FREE_IT da instrução DECLARE EXTERNALFUNCTION. Em contraste, no modelo Clássico, por haver um processo separado para cadaconexão de cliente, as UDFs estão garantidas que não conflitarão. Variáveis globaissão seguras para utilização. Também espaços perdidos de memória não sãoperigosos, porque qualquer espaço perdido é liberado quando o cliente sedesconecta. Portanto a recomendação é que o uso de UDFs para o SuperServer deve ser
  • 5. mais restrito do que o uso no modelo Classic. Se você utiliza o modelo Classic, certifique-se de que suas UDFs 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. 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 multi- usuá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. Artigo Original:http://www.ibphoenix.com/main.nfs?a=ibphoenixApp&l=;IBPHOENIXAPP.PAGES;NAME=ibp_ss_v s_classic Equipe da IBPhoenix www.ibphoenix.com Tradução e adaptação: Comunidade Firebird de Língua Portuguesa Visite a Comunidade em: Paulo Vaz paulo@multi-informatica.com.br http://www.comunidade-firebird.org A Comunidade Firebird de Língua Portuguesa foi autorizada pelo Autor do Original para elaborar esta tradução.