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.

segunda-feira, 21 de agosto de 2017

Dell PowerEdge R730: RAID5 SATA vs SSD: Desempenho de gravação

O teste mede a performance de gravação em um Servidor PowerEdge r730 da DellEMC com duas opções de discos:

  1. RAID5 com 4 discos SATA 7.500 RPM de 02TB cada, montado em /dados;
  2. Disco SSD de 200GB, montado em /ssd;
O SSD (solid-state drive) é um disco rápido e caro. Contudo, quanto mais rápido ele é? Este post tenta responder esta pergunta.

Metodologia do Teste

Consiste em gravar um arquivo de 10GB de dados, via comando DD, conforme comando:
dd if=/dev/zero of=dados.dat bs=20480000 count=512

O comando dá a taxa de gravação em BYTES. O Cache dos discos ajudam a melhorar o desempenho, portanto quanto maior a quantidade de dados gravada, mais real será a taxa de gravação apresentada, por este motivo o teste realizado utilizou 10GB.
Sistema Operacional instalado na máquina foi o Linux CentOS:

Dados do servidor: Power Edge R730
Memória: 128GB DDR4
CPU: 2 XEON E5-2640 v4
Discos: 4 SATA 7,5k RPM 2TB e 1 SSD 200GB


Resultado

/dados (RAID 5 com 4 discos SATA 7,5k RPM de 02 TB):
RAID5 com 4 Discos SATA = 443 MB/s de gravação.
Os 4 discos em RAID05 apresentaram uma taxa de gravação de 443MB/s. Apenas como curiosidade, a medição de gravação em um único disco SATA seria de aprox. 125MB/s.

/ssd (Disco SSD de 200GB):
Disco SSD = 1.500 MB/s de gravação.
O único disco SSD apresentou uma taxa de gravação de  1.500MB/s (1,5 GB/s). Incrível!

Conclusão

TestePerformance: RAID5 com 4 discos SATA versos SSD.

A diferença na velocidade de gravação é nítida, um único disco SSD possui taxa maior que três vezes a de um RAID5 com 4 discos SATA.

Espero que com estas informações você consiga tomar melhor decisão na definição de disco em seus projetos.
Esta máquina, no caso, irá trabalhar com duas áreas: uma rápida (SSD) e outra lenta (RAID05 SATA), afim de alcançar o melhor custo benefício.

quinta-feira, 2 de junho de 2016

Storage: Deduplicação Funciona?

Deduplicação (ou Desduplicação) é uma técnica que visa economizar espaço em disco através da eliminação de redundância de dados.
A otimização promete ganhos de até 90%, mas será que é verdade? Vamos ver...

Tipos de Deduplicação

Há dois tipos básicos de deduplicação:
1) Baseado em Arquivos: Caso exista cópias de um mesmo arquivo no volume, apenas o tamanho de um arquivo será ocupado no disco.

2) Baseado em Blocos: Caso exista arquivos com "pedaços" (blocos) idênticos no volume, apenas uma instância do pedaço será ocupada no disco.

Para a maioria dos casos, a Deduplicação Baseada em Blocos é mais eficiente. Apenas storages de alto nível possuem baseado em Bloco, por exemplo os da marca NetApp.
Storages simples (Exemplo: QNAP) utilizam deduplicação baseada em arquivos.

Dedup na prática com Storage NetApp

Segundo a NetApp os ganhos com Deduplicação são gigantescos. Veja a tabela abaixo:


Mas, e na prática? É o que vamos testar. Será utilizado um storage de NetApp modelo FAS-2554.

Teste 01: Ambiente de Backup

O ambiente de backup utilizado no teste possui dados gerais: servidores, banco de dados, dados de usuários, etc. O sistema de backup faz compactação de arquivos (ZIP).
Segue tela após o agendamento da execução da desduplicação no:

No ambiente testado conseguimos apenas 25% de economia. Segundo a propaganda da NetApp deveria ser 90%. Pode ser que no ambiente testado pela fabricante não utilizou compactação de arquivos.
Em todo caso, o resultado foi interessante, uma vez que os arquivos estavam compactados. E, a ativação da funcionalidade não implicou em perda de performance, pois funciona em período pré-agendado.

Teste 02: Ambiente de Virtualização

O ambiente de virtualização utilizado no teste possui 20 maquinas virtuais de Windows Server e de Linux Debian.
Todas as máquinas virtuais utilizam alocação dinâmica de disco, ou seja se uma maquina virtual possui um disco de 1TB, mas está utilizado 100GB, então o espaço em disco no storage será de 100GB. É neste ambiente que veremos qual é a eficiência do Dedup.
Segue tela após o agendamento da execução da desduplicação:

Deduplicação ambiente de Virtualização - Netapp
No ambiente testado conseguimos a incrível marca dos 44% de economia. Segundo a propaganda da NetApp deveria ser 70%. Pode ser que no ambiente testado pela fabricante não foi utilizado a alocação dinâmica de dados das máquinas virtuais.
Em todo caso, o resultado foi impressionante e a ativação da funcionalidade não implicou em perda de performance.

Conclusão

Deduplicação em storage (da NetApp) pode trazer grandes economia, mas o resultado obtido na prática é menor do que o anunciado.

quarta-feira, 18 de maio de 2016

LDAP: Teste de Performance com JMETER

O LDAP é um protocolo de acesso a Diretórios, que por sua vez é uma organização de dados em árvore com objetivo de responder rapidamente uma consulta.
Muitos sistemas trabalham com Diretório e disponibilizam interface LDAP: Windows com Active Directory, OpenLDAP, etc.
Um Serviço de Diretório é utilizado por todos os outros serviços da rede, por exemplo: para verificar a autenticação. Portanto, é natural questionar se um determinado servidor LDAP irá suportar a carga.
A ferramenta utilizada para checar a performance do serviço será o JMETER. No link mostra como instalar.

O servidor testado foi Ubuntu Linux, virtualizado (1GB RAM e 2 CPUs), com OpenLDAP 2.4.44. Mas, o mesmo teste poderia ser executado em um servidor Windows com AD ou outro servidor de Diretório.

Plano de teste

O plano de teste foi desenvolvido para simular 500 usuários acessando o Diretório ao mesmo tempo. Cada usuário realizará 25 requisições de pesquisa (SEARCH) no servidor LDAP, ou seja totalizando 12.500 requisições. A figura abaixo mostra a configuração do plano de teste:

LDAP: Simulando 500 usuário simultaneamente.
Configuração de pesquisa LDAP.
Cada requisição irá representar um SEARCH com o filtro (uid=fulano1) na base LDAP.

Resultado

O Servidor LDAP começou falhar na requisição de número 954:

Depois, entrou em colapso e não respondeu mais nada depois da requisição de número 1150:

Trinta minutos depois o teste ainda não tinha sido concluído, veja o resultado sumarizado:
Teste final parcial
Fiquei curioso para saber o que havia ocorrido com o servidor LDAP, então visualizei os logs:

May 14 20:47:39 ldapsrv slapd[1150]: warning: cannot open /etc/hosts.allow: Too many open files
May 14 20:47:39 ldapsrv slapd[1150]: daemon: accept(8) failed errno=24 (Too many open files)
May 14 20:47:39 ldapsrv slapd[1150]: warning: cannot open /etc/hosts.deny: Too many open files
May 14 20:47:39 ldapsrv slapd[1150]: fd=1023 DENIED from unknown (192.168.0.102)

...

Segundo o Log acima, é possível concluir que uma das limitações foi a configuração do número máximo que um arquivo pode ser aberto por processo, no Sistema Operacional, isto limitou o servidor LDAP. O sistema operacional do servidor estava limitado a abrir apenas 1024 vezes um arquivo.

Obs.:  O arquivo /etc/hosts.deny é utilizado para checar se uma máquina(IP) pode ou não utilizar determinado serviço, análogo a um firewall. O arquivo é lido a cada nova solicitação de conexão.

Após o OpenLDAP ser reiniciado no servidor, o teste concluiu rapidamente. Segue resultado final:
Teste final.

Considerando a limitação de abertura de arquivos do servidor, foi proposto um novo plano de teste mais simples, apenas 200 usuários com 10 requisições cada. Veja abaixo o gráfico da latência (tempo de resposta) das requisições conforme o tempo de execução do teste: 

Gráfico Latência Requisições LDAP.
O OpenLDAP fez seu papel, manteve o tempo de resposta constante após o inicio das conexões.

Conclusão

O primeiro ponto a destacar é que o TUNNING do Sistema Operacional do Servidor é importantíssimo para o desempenho da Aplicação. No plano de teste executado, o OpenLDAP teve seu desempenho comprometido pelas limitações do Sistema Operacional Linux.
Segundo ponto, o JMETER é uma ferramenta sensacional para testes de performance de servidores: Em 15 minutos é possível desenvolver e executar um plano de teste no Serviço de Diretório LDAP.

segunda-feira, 16 de maio de 2016

JMETER Apache – Teste de Carga em Servidores Web

JMETER é uma ferramenta utilizada para realizar teste de carga em servidores, ele é grátis e 100% desenvolvido em Java.
Teste em servidores WEB é a funcionalidade mais conhecida, mas testes em outros servidores/protocolos também são possíveis, segue lista completa:
  • Web - HTTP, HTTPS
  • SOAP
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail - SMTP(S), POP3(S) e IMAP(S)
  • MongoDB (NoSQL)
  • Comandos de Shell Scripts
  • TCP
O teste pode ser realizado em paralelo, com o uso de “threads”. Seria como uma simulação de acessos simultâneos.
A interface gráfica auxilia no desenvolvimento do plano de teste e na analise dos resultados.

Requisitos mínimos para executar o JMeter

  • Interpretador Java: Compatível com Java 6 ou maior.
  • Arquivos jars Opcionais: Muitos jars não estão inclusos no JMeter. Se necessário, fazer o download e salvar no diretório de bibliotecas (lib).

Download e Execução

O JMeter está disponível em http://jmeter.apache.org/download_jmeter.cgi.
Basta fazer o download e descompactar. Será criado uma árvore de diretórios e o arquivo principal está no diretório “BIN”.
  • Execução no Windows: jmeter.bat
  • Execução no *unix: jmeter
Tela Inicial do JMETER

Plano de Teste

Qualquer teste no JMETER precisa de um plano de teste. Para melhor entendimento vou executar um plano de teste de carga em um servidor WEB. Siga os passos...

Passo 01: Definição dos Grupos

Clique no Plano de Teste com o Botão Direito do Mouse, conforme mostrado abaixo:

JMETER: Adicionando Grupo de Usuários


Configuração de threads (usuários e requisições)


O campo "Número de Usuários Virtuais (threads)" representa a quantidade de usuários que irão acessar o servidor web ao mesmo tempo, no caso 100. Cada usuário fará 10 requisições, representado no campo "Contador de Iteração".

Passo 02: Testador HTTP (WEB)

Clique em "Grupo de Usuários" com o botão direito do Mouse, selecione Adicionar, Testador, Requisição HTTP. Conforme mostrado abaixo:
JMETER: Testador HTTP

Passo 03: Configurando servidor HTTP alvo

Configurar o IP do servidor, no caso 192.168.0.103, e a porta, 80. Conforme mostrado abaixo:
Configurando IP e Porta do servidor HTTP alvo

Passo 04: Adicionando Ouvinte

Afim de facilitar a visualização do resultado do teste, é necessário adicionar alguns ouvintes. Clique com o botão direito do mouse em "Grupo de Usuários" e selecione Adicionar, Ouvinte, Relatório Agregado, conforme mostrado abaixo:
JMETER: Relatório Agregado
Faça o mesmo para Relatório de Sumário, conforme mostrado abaixo:
JMETER: Relatório de Sumário
O plano de teste está definido, agora vamos executar, siga o passo 05.

Passo 05: Iniciando o Teste


Clicar no ícone PLAY (SETA VERDE) para iniciar o teste:
Iniciar o teste no JMETER
Após alguns segundos o teste irá terminar. Será que o servidor web suportou a carga?

Passo 06: Visualizando o resultado do teste

Através dos Ouvintes adicionados no passo 04, podemos observar o resultado do teste:
JMETER: Resultado do teste de carga no Servidor Web





O resultado mostrou que o servidor foi capaz de suportar o teste de 100 usuários, fazendo 10 requisições cada, ao mesmo tempo. Ou seja 1000 requisições.
O servidor Web testado foi o Ubuntu Linux virtualizado com: 1 GB RAM e 3 CPUs. 


Obs.: O servidor não suportou a mesma carga com 1000 usuários, ou seja 10.000 requisições. Cerca de 13% das requisições não foram atendidas.

Conclusão

O JMETER é uma ferramenta poderosa em teste de carga e muito simples de utilizar. Futuramente pretendo testar os outros Testadores da ferramenta: LDAP, SOAP, FTP e MAIL.Há outros relatórios (ouvintes) mais detalhados na ferramenta, que não foram demonstrados aqui. A inserção destes segue o mesmo procedimento dado no passo 04 (Adicionando Ouvinte) deste artigo.