[firebase-br] Limites do Firebird

Miguel miguel em franca.sp.gov.br
Qui Fev 15 17:59:42 -03 2007


Bom. 

Cada banco em servidores diferentes é inviável, impossível, fora de cogitação, improvável, inimaginável, inadmissível ou qualquer "in","im","des","etc.."(rsrsrs)  que você souber, visto que temos mais de 60 bancos diferentes no SQL Server. (Estamos migrando!).

Mas você disse que se eu tiver três objetos de conexão na minha aplicação, apontando para bancos diferentes num mesmo servidor, o Firebird conta como sendo três conexões. Tá, mas e se eu abrir essa aplicação em 4 estações diferentes?! Serão ainda as mesmas 3 conexões ou agora serão 12(3 conexões vezes 4 máquinas)? Eu queria ter um número aproximado ou exato disso porque o tal do 930 num me sai da cabeça. Explico. Tenho uma DLL que faz as conexões pra mim. Em uma conexão, o usuário só faz selects na outra o resto (insert, update, delete). Isso pra controle meu. Então, para cada banco eu já faço duas conexões. Na aplicação em questão, tenho somente 5 usuários. Mas, se todos abrem ao mesmo tempo eu tenho 10 conexões. É isso?! Porque se for, quando eu tiver 465 usuários (Não é dificil isso em WEB!!) fazendo duas conexões chego no tal número 930.

Porque essa preocupação?! O Primeiro sistema que vou migrar trabalha com 9 bancos diferentes. O Segundo trabalha com 13 bancos. (Eu tenho só em sistemas Cliente/Servidor um número aproximado de 68.

Se eu migrar só os 2 sistemas citados então cada usuário com os dois sistemas abertos teria 24 conexões! 

E aí.. Como isso funciona?!
    ----- Original Message ----- 
    From: Eduardo Jedliczka (TeamFB) 

    na prática, você pode ter várias conexões entre um computador e outro numa mesma porta / protocolo.

    se você usa eventos, você tem conexões entre o cliente e o servidor independente das suas conexões principais, se utiliza serviços como GBAK, GFIX, também tem outras conexões. mas em resumo cada Tconnection é uma 
    conexão. Se tiver conectado em 3 bases diferentes, terá (pelo menos) 3 conexões simultâneas.

    Sucesso,

    Eduardo Jedliczka
    Membro do TeamFB

    ----- Original Message ----- 
    From: "Campus" 

    Eduardo me esclarece uma coisa, como essas conexões são contadas, é algo
    entre a FBCclient->FBServer, ou cada objeto XConnection da aplicação ?

    ----- Original Message ----- 
    From: "Eduardo Jedliczka (TeamFB)

    Bom, vamos lá.

    Quando eu falar processador, leia-se núcleo de processamento.

    Não conheço pessoalmente, e segundo algumas informações sobre casos de
    sucessos do FB SuperServer com mais de 80 conexões concorrentes numa base
    com mais de 5 milhões de registros. O problema é o consumo de memória e CPU
    (o SS só endereça 2GB de ram, e só utiliza um processador).

    O Classic Server, mesmo gastando mais CPU e muuuuito mais memória, pode
    endereçar 2GB por conexão mas cada processo roda num único processador. Isto
    significa, que num servidor multiprocessado com vários GB de ram, o classic
    consegue atender infinitamente mais conexões do que o Super Server. E há
    casos de sucesso com mais de 300 conexões concorrentes num FireBird classic.
    (eu particularmente vejo comumente até 180 concorrentes).

    Mas há um detalhe, o  limite do NetBEUI  não tem nada a ver com o limite do
    TCP/IP ou de conexões locais.  Se não me engano, o limite de conexões do
    TCP/IP para uma única porta é 16381 (2^16 - 3) mas cada coxeção consome
    memória e principalmente CPU.

    Se você tiver vários servidores WEB apontando para um único servidor de
    banco de dados, precisa pensar muito no tempo de transação (e consumo de
    memória e processador). Se precisar dar um sort com algumas dezenas/centenas
    de milhares de registros... aquele Dual Xeon 3535 (quad-core) com 32 GB de
    ram pode ser insuficiente para atender 4 ou 5 mil conexões. Em
    contrapartida, se você tiver tabelas extremamente normalizadas, com índices
    eficientes, e selects com pouquíssimos registros sem group by ou sorts
    grandes, e não utilizar blobs, talvez um Pentium 4 com 1 ou 2 gb de ram
    consiga atender mais do que mil conexões concorrentes.

    Sendo assim, eu recomendaria, (até por uma questão de segurança e custos),
    colocar cada banco de dados num servidor diferente (não pelo limite de
    conexões, mas sim pelo custo de se ter um servidor parrudo).

    Sucesso,

    Eduardo Jedliczka
    Membro do TeamFB




Mais detalhes sobre a lista de discussão lista