quinta-feira, 23 de agosto de 2018

Desempenho de Banco de dados MySQL em servidor VPS Locaweb

Servidor VPS (Servidor Virtual Privado) é uma alternativa barata para hospedagem, mas qual será sua capacidade?
Utilizamos menor VPS oferecido pela LOCAWEB:
Servidor VPS mais simples oferecido pela LOCAWEB.

VPS é caracterizado por compartilhamento de recursos da máquina física, há caso onde um CPU é compartilhado por até 100 máquinas virtuais. O ponto positivo é o preço baixo. Com R$ 17,90 você tem um servidor Linux com 512MB de RAM, 20GB de disco SSD e um endereço IP válido na Internet.
O compartilhamento de recursos assusta as pessoas que estão interessadas no serviço, pois há risco de lentidão em alguns momentos. Para auxiliar na sua decisão, resolvemos testar uma aplicação simples de cadastro e consulta em banco de dados.

Metodologia do teste

Consiste em executar um script que lê campos de um arquivo CSV (Comma-Separated Values), consulta se registro existe e então grava-os em um Banco de Dados MYSQL. A tabela alimentada possui 10 campos e 16.000 registros, com tamanho total de 20MB.
O teste realiza leitura (50% Select) e cadastro (50% Insert) na base dados.

Características do ambiente

Sistema Operacional: Linux Debian 64 Bits
Sistema de Banco de Dados: Mysql
VPS: 512MB hospedado na LOCAWEB (Contratado exclusivamente para este teste)
Outros programas instalados: PHP, APACHE e PHPMYADMIN.

Resultados

Status de utilização antes do início do teste (em repouso):

Status do servidor de Banco de Dados em repouso, antes do teste.

Após iniciarmos os testes, o status mudou:

Status do Servidor após inicio do teste: 50% Select e 50% Insert.

Analise e conclusão

O principal "gargalo" foi o CPU (processador), que imediatamente após iniciar o teste alcançou os 100% de utilização. Se você precisa de uma máquina que faz no máximo 450 transações por segundo, então o VPS apresentado irá lhe atender, caso contrário a máquina irá congelar.

quarta-feira, 20 de junho de 2018

LDAP vs LDAPS vs LDAPI: Performance?

O LDAP (Lightweight Directory Access Protocol) é um protocolo para acessar e manter serviços de Diretório. Amplamente utilizado para acessar serviço implementado com Windows AD, OpenLDAP, etc. Definição:

LDAP: Acesso a Diretório sem ou com criptografia habilitado (TLS) através da rede;
LDAPS: Acesso a Diretório com criptografia (SSL) através da rede;
LDAPI: Acesso a Diretório sem criptografia através de Comunicação entre Processos (IPC, Inter-Process Communication);

O teste consiste em medir o tempo necessário para execução de três experimentos com 1, 100 e 1.000 consultas (LDAP SEARCH).

Segue abaixo o script chamado "testeperformance.pl", desenvolvido em PERL, para realização dos testes:

#!/usr/bin/perl -w

($protocolo,$ntentativas) = @ARGV;

if ($protocolo eq "ldap") {
    use Net::LDAP;
    for (my $i=0; $i < $ntentativas; $i++) {
        $ldap = Net::LDAP->new( 'ldap://192.168.0.1' ) or die "$@";
        $mesg = $ldap->bind ;    # an anonymous bind
        $mesg = $ldap->search( # perform a search
                       base   => "dc=testeperformance",
                       filter => "(cn=fulano1)"
                     );
        $mesg->code && die $mesg->error;
        $mesg = $ldap->unbind;   # take down session
    }
}

if ($protocolo eq "ldaps") {
    use Net::LDAPS;
    for (my $i=0; $i < $ntentativas; $i++) {
        $ldaps = Net::LDAPS->new( 'ldaps://testeperformance',verify => 'allow',
                         capath => '/etc/ldap/tls/') or die "$@";
        $mesg = $ldaps->bind ;    # an anonymous bind
        $mesg = $ldaps->search( # perform a search
                       base   => "dc=testeperformance",
                       filter => "(cn=fulano1)"
                     );
        $mesg->code && die $mesg->error;
        $mesg = $ldaps->unbind;   # take down session
    }
}

if ($protocolo eq "ldapi") {
    use Net::LDAPI;
    for (my $i=0; $i < $ntentativas; $i++) {
        $ldapi = Net::LDAPI->new( '/var/run/ldapi' ) or die "$@";
        $mesg = $ldapi->bind ;    # an anonymous bind
        $mesg = $ldapi->search( # perform a search
                       base   => "dc=testeperformance",
                       filter => "(cn=fulano1)"
                     );
        $mesg->code && die $mesg->error;
        $mesg = $ldapi->unbind;   # take down session
    }
}


Modo de utilizar o script:

# perl testeperformance.pl <PROTOCOLO> <Número de Tentativas>

O parâmetro <PROTOCOLO> pode ser "ldap", "ldaps" ou "ldapi". E o <Número de Tentativas> é um inteiro que indica o número de vezes que o script irá executar a consulta. 
Obs.: Caso você tenha interesse em testes mais profundos no servidor de Diretório, recomendo utilizar o JMITER.

Experimentos

Foram executados em uma máquina virtual na nuvem, com a seguinte configuração:
Processador: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
Memória: 2 GB
Disco: 40 GB
Sistema Operacional: Linux Debian - 64 Bits
Sistema de Diretório: OpenLDAP 2.4.46 

A operação de busca, SEARCH, é a mais utilizada em Diretórios, por este motivo iremos testar apenas esta operação. O terceiro experimento consiste em medir o tempo de execução de 1.000 consultas, afim de reproduzir ambientes de produção como por exemplo serviço de e-mail.
A implementação é sequencial, ou seja, uma nova busca será executada depois da conclusão da anterior. Este é o comportamento da maioria dos sistemas, mas há casos onde a implementação é paralela, ou seja consultas simultâneas. Não foi considerado consultas simultâneas neste teste de performance. 

Experimento 01: Apenas uma consulta

Consiste em medir o tempo necessário para execução de uma consulta (search) nos diferentes protocolos.
Exemplo comando executado:
# time perl testeperformance.pl <PROTOCOLO> 1


Resultado experimento com uma tentativa:
LDAP: 0,065s
LDAPS: 0,094s
LDAPI: 0,065s

Experimento 02: 100 consultas sequenciais

Consiste em medir o tempo necessário para execução de 100 consultas (search) repetidas nos diferentes protocolos.
Exemplo comando executado:
# time perl testeperformance.pl <PROTOCOLO> 100



Resultado experimento com uma tentativa:
LDAP: 0,195s
LDAPS: 0,749s
LDAPI: 0,155s

Experimento 03: 1.000 consultas sequenciais

Consiste em medir o tempo necessário para execução de 1.000 consultas (search) repetidas nos diferentes protocolos.
Exemplo comando executado:
# time perl testeperformance.pl <PROTOCOLO> 1000

Resultado experimento com uma tentativa:
LDAP: 1,292s
LDAPS: 6,833s
LDAPI: 0,996s


Resumo dos experimentos

Teste de Performance: LDAP vs LDAPS vs LDAPI


Conclusão

Como era de se esperar, o LDAPS é até cinco vezes mais lento que o LDAP, por causa dos procedimentos necessários para segurança (Criptografia).
O resultado que surpreendeu foi a agilidade do LDAPI, que chegar ser 20% superior ao protocolo padrão. A justificativa é que IPC não precisa se preocupar com as validações de rede (CHECKSUM, MTU, encapsulamento, cabeçalho, endereçamento).

Observação

Há limitação na quantidade de conexão simultânea quando utilizamos o LDAP ou LDAPS. Depende do sistema operacional mas este número geralmente é de 32768 conexões simultânea. Não faz parte da performance, mas é interessante ressaltar que o LDAPI é ilimitado.

 

segunda-feira, 4 de junho de 2018

PyKota VS IBQUOTA: Qual o contador de páginas mais rápido?

Os sistemas mais conhecidos no mundo OpenSource para controle de impressão são: o PyKota e o IBQUOTA. Há questionamentos, especialmente nas listas de discussão, sobre qual sistema computa a quantidade de página de um job mais rapidamente. Este artigo tem como finalidade realizar alguns testes e responder o questionamento.

IBQUOTA

Site: www.ib.unicamp.br/ibquota
Linguagem de Programação: Perl (Contador de páginas)
Início do Projeto: Ano 2003

PyKota

Site: www.pykota.com
Linguagem de Programação: Python
Início do Projeto: Ano 2003

Ambiente utilizado no Teste

Sistema Operacional: Linux Debian 3.16 (64 Bits)
Processador CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
Memória RAM: 4 GB
Contador IBQUOTA: Versão 2.4.1
Contador PyKota: v3.50


Foi utilizado a configuração padrão, não houve refinamento de configuração para executar o teste.

Metodologia 


A metodologia utilizada no teste consiste em medir o tempo de CPU utilizado pelo contador de página para analisar arquivos do tipo PostScript e PCL. O comando "time" foi utilizado.

Teste 01: Arquivo formato PostScript com 1 página

O primeiro teste é bem pequeno, simula uma impressão de uma única página. Arquivo utilizado no teste está disponível AQUI. Tamanho do arquivo é de 15K.

IBQUOTA: 
# time perl pagecount.pl samplec.ps
Iniciando IBQUOTA...
FORMATO=PS-PostScritp
PS=1

real    0m0.018s
user    0m0.004s
sys    0m0.004s



PyKota:
# time /usr/bin/pkpgcounter samplec.ps
1

real    0m0.125s
user    0m0.088s
sys    0m0.032s


Resultado Teste 01: IBQUOTA se mostrou mais ágil para computar as páginas de um job pequeno no formato PostScript.


Teste 02: Impressão de arquivo Formato PCL com 11 páginas

Segundo teste com um arquivo maior, com tamanho de 125KB. O formato do arquivo é PCL e possui 11 páginas. Este formato é muito utilizado por impressoras da HP.

IBQUOTA: 
# time perl pagecount.pl sample.pcl
Iniciando IBQUOTA...
FORMATO=PCL
PCL=11

real    0m0.361s
user    0m0.196s
sys    0m0.164s


PyKota:
# time /usr/bin/pkpgcounter sample.pcl
11


real    0m0.369s
user    0m0.344s
sys    0m0.024s


Resultado Teste 02: Neste teste os dois contadores tiveram performance relativamente iguais, o IBQUOTA foi ligeiramente mais rápido.

Considerações

Além da função de computar a quantidade de páginas, há uma função adicional realizada para identificar o formato do arquivo. Esta tarefa foi executada pelos dois programas e o tempo de execução está somado ao total. Se o formato do arquivo fosse indicado, o tempo de execução seria reduzido, e poderia mudar o resultado final.

Não há diferença significativa na performance dos sistemas testados.