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.

quarta-feira, 11 de maio de 2016

FreeBSD: ISO Padrão ou preparado para Virtualização (Virtual Machine image)

O FreeBSD é um sistema operacional baseado no UNIX, é um "concorrente" do Linux.
Este sistema operacional é conhecido por sua Estabilidade, Robustez, Velocidade e Segurança, se comparado com outros sistemas operacionais (em ambiente não virtualizado). Mas, hoje é raro ambiente que não seja virtualizado.

Quando virtualizado, o FreeBSD perde muita performance, se comparado com o Linux. Então, os desenvolvedores resolveram criar uma imagem personalizada para virtualização, ela é chamada de "FreeBSD Virtual Machine Image".

O objetivo deste post é comparar o desempenho do FreeBSD padrão com o preparado para virtualização em um ambiente Virtualizado. Será que tem vantagens ou é apenas frescura?

1. Host (máquina física) utilizado no teste

A máquina utilizada para realizar os testes possui as seguintes características:
Memória RAM: 8 GB
Processador: Intel i5
Disco: 1TB SATA2

É um desktop convencional. Nada de mais!

2. Imagens

O FreeBSD pode ser baixado AQUI. As máquinas virtuais dos testes possuem as seguintes características:
Memória RAM: 1 GB
Processador: 4 CPUs


São dois tipos de imagem:

2.1. Virtual Machine Image

A versão preparada para virtualização só está disponível para as arquiteturas: i386 e AMD64.
Está disponível para vários tipos de hypervisors e formatos de arquivos:
vhd: VirtualPC, Hyper-V, Xen, VirtualBox
vmdk: VMWare
qcow2: Qemu, KVM, VirtualBox
raw: bhyve, ou outro hypervisors com suporte ao formato "raw disk image".

No caso do teste, foi selecionado o "FreeBSD-10.3-RELEASE-i386.vhd.xz". Basta descompactar e criar uma nova máquina virtual no VirtualBox, e selecionar o arquivo baixado com o disco da VM, conforme mostrado abaixo:
VirtualBox: FreeBSD Virtual Machine image
A máquina virtual já vem instalada, mas está zerada. É necessários executar alguns comandos:

Ativar IP na máquina:
# dhclint em0

Baixar os pacotes para instalação de outros softwares:
# portsnap fetch
# portsnap extract

Instalar as ferramentas de teste:
# cd /usr/ports/security/john
# make install
# cd /usr/ports/benchmark/iperf
# make install

2.2. Imagem padrão do FreeBSD

Este é o tipo mais comum de se instalar o FreeBSD. É tão simples que não entrarei em detalhes. Também é necessário instalar as ferramentas de teste, conforme mostrado no item anterior.

3. Teste de performance

O Teste consiste em testar a velocidade de Gravação em disco, Processamento com openssl (criptografia) e rede com Iperf.

3.1. Teste de Gravação em disco

O comando "dd" foi utilizado para testar a performance de gravação do disco. O comando utilizado para gerar um arquivo de 5GB:

# dd if=/dev/zero of=dados.dat bs=10000000 count=512

FreeBSD preparado para Virtualização. Teste gravação em disco.
FreeBSD padrão. Teste de gravação em disco.
O teste foi realizado três vezes seguidas, e o resultado foi a média dos valores.
Resultado final de gravação:


Gravação em Disco com o DD FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 47,3 MB/s 51,3 MB/s
Tentativa 02 48,5 MB/s 51,2 MB/s
Tentativa 03 49,8 MB/s 50,8 MB/s
Média Final 48,5 MB/s 51,1 MB/s

Diferente do resultado esperado, a VM com FreeBSD padrão teve performance de gravação 5% superior a VM com FreeBSD preparada para virtualização.

Obs.: No host, máquina utilizada para virtualizar as MV acima, o mesmo comando fez a gravação em 110MB/s.

3.2. Teste Processamento com openssl - rsa 4096

Para testar o processamento das máquinas virtuais foi utilizado a ferramenta "openssl". O teste consiste em identificar a quantidade de verificação RSA de 4096 bits as MVs fazem por segundo. Isto é criptografia pura e usa muito CPU. Comando executado:
# openssl speed rsa4096

FreeBSD preparada para Virtualização. Teste de processamento com openssl.
FreeBSD padrão. Teste de processamento com openssl.

Resultado final do teste de processamento:


Processamento com o openssl – RSA 4096 FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 1771,8 1855,2
Tentativa 02 1844,6 1783,0
Tentativa 03 1774,1 1770,3
Média Final 1796,8 1802,8

No teste de processamento, também teve resultado inesperado: A VM com FreeBSD padrão teve desempenho de CPU levemente superior a VM preparada para virtualização.

Obs.: No host, a medida foi de: 1820,3.

3.3. Teste de velocidade de Rede

O "iperf" é uma ferramenta simples para testar a velocidade de rede entre duas máquinas, para saber mais leia aqui. A versão é a 2.0.5.
O ambiente de teste foi montado em cima de rede gigabit Ethernet.
Neste caso, o teste também foi repetido três vezes e o resultado final é a média dos testes.
A máquina virtual assumiu o lado client do iperf, comando:
# iperf -c IP_SERVIDOR_IPERF
Outra máquina, identificado por IP_SERVIDOR_IPERF acima, não é virtualizada. Ela está na rede e fez papel de servidor, nos dois casos.
FreeBSD preparado para Virtualização. Teste de rede com IPERF.
FreeBSD padrão. Teste de rede com IPERF.

Resultado final do teste de rede:


Velocidade de rede com o iperf FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 407 Mbits/s 403 Mbits/s
Tentativa 02 409 Mbits/s 409 Mbits/s
Tentativa 03 413 Mbtis/s 421 Mbits/s
Média Final 409,66 Mbits/s 411 Mbtis/s

Mais uma vez, a VM padrão do FreeBSD se mostrou mais performática que a VM preparada para Virtualização.

Obs.: No host, o teste chegou a 821 Mbits/s.

4.0 Resultado final dos testes

A tabela abaixo apresenta o resumo dos testes nos dois FreeBSD:


Teste \ VM FreeBSD Preparado para Virtualização FreeBSD Padrão Diferença
Gravação em Disco 48,5 MB/s 51,1 MB/s 5,09%
Performance de Rede 409,66 Mbits/s 411 Mbtis/s 0,33%
Velocidade de Processamento 1796,8 1802,8 0,22%

Os três testes mostraram que o desempenho da Máquina Virtual de FreeBSD padrão é mais performático com a VM preparada para virtualização.

5.0 Conclusão

O FreeBSD é um Sistema Operacional muito apreciado pelos usuários tradicionais, ele não aparece muito na mídia, igual o Linux.
Ambientes não virtualizados é praticamente impossível nos dias de hoje. E, geralmente, o Linux é superior ao FreeBSD em ambientes Virtualizados. Isto fez com que o uso do FreeBSD caísse ainda mais.
Os testes mostraram que o FreeBSD preparado para virtualização NÃO aumenta o desempenho, pelo contrário: nos três testes (gravação de disco, Rede e Processamento) ele possui performance inferior.
Infelizmente o FreeBSD irá continuar a perder espaço para o Linux.