Postado por Blogger às 22:46 Nenhum comentário:
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:
($protocolo,$ntentativas) = @ARGV;
if ($protocolo eq "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") {
$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
$mesg = $ldaps->unbind; # take down session
if ($protocolo eq "ldapi") {
use Net::LDAPI;
$ldapi = Net::LDAPI->new( '/var/run/ldapi' ) or die "$@";
$mesg = $ldapi->bind ; # an anonymous bind
$mesg = $ldapi->search( # perform a search
$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.
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
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.
# time perl testeperformance.pl <PROTOCOLO> 100
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.
# time perl testeperformance.pl <PROTOCOLO> 1000
LDAP: 1,292s
LDAPS: 6,833s
LDAPI: 0,996s
Resumo dos experimentos
Teste de Performance: LDAP vs LDAPS vs LDAPI
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).
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.
Postado por Blogger às 11:22 Nenhum comentário:
Marcadores: Diretório, LDAP, LDAPI, LDAPS, OpenLDAP, PERL, SSL, Teste de Performance
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.
Site: www.ib.unicamp.br/ibquota
Linguagem de Programação: Perl (Contador de páginas)
Início do Projeto: Ano 2003
Site: www.pykota.com
Ambiente utilizado no Teste
Sistema Operacional: Linux Debian 3.16 (64 Bits)
Processador CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
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.
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
PyKota:
# time /usr/bin/pkpgcounter samplec.ps
real 0m0.125s
user 0m0.088s
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.
# time perl pagecount.pl sample.pcl
FORMATO=PCL
PCL=11
user 0m0.196s
# time /usr/bin/pkpgcounter sample.pcl
real 0m0.369s
user 0m0.344s
Resultado Teste 02: Neste teste os dois contadores tiveram performance relativamente iguais, o IBQUOTA foi ligeiramente mais rápido.
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.
Postado por Blogger às 11:37 Nenhum comentário:
Marcadores: contador de páginas, IBQUOTA, Pagecount, PCL, PostScript, Pykota
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:
RAID5 com 4 discos SATA 7.500 RPM de 02TB cada, montado em /dados;
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.
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
/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!
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.
Postado por Blogger às 16:27 Um comentário:
Marcadores: dd, Dell, Gravação, performance, PowerEdge r730, SATA, SSD, Teste de Performance
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.
Deduplicação em storage (da NetApp) pode trazer grandes economia, mas o resultado obtido na prática é menor do que o anunciado.
Postado por Blogger às 21:07 Nenhum comentário:
Marcadores: dedup, Deduplicação, Desduplicação, Netapp, Storage
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.
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.
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:
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.
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.
Postado por Blogger às 13:52 Nenhum comentário:
Marcadores: Diretório, JMETER, LDAP, Teste de Performance
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:
Mail - SMTP(S), POP3(S) e IMAP(S)
Comandos de Shell Scripts
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
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.
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.