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.

quarta-feira, 4 de maio de 2016

Quantas cifras por segundo meu PC consegue testar?

Com o Hash de uma senha é possível encontrar, depois de muito processamento, o texto equivalente através de força bruta. O ataque por força bruta consiste em testar todas as possibilidades até encontrar a senha correta.
O Hash pode ser em MD5, LM, SHA, CRYPT, etc. Cada um deste possui dificuldade distinta.

Objetivo do teste

Identificar quantas cifras o PC i7 com 8GB de RAM, com Linux, consegue gerar em apenas 1 segundo.

Atividade

A ferramenta "John the Ripper" oferece um parâmetro "-test" que gera um benchmark das cifras mais conhecidas. Veja o resultado:

root@info:/home# john -test
Created directory: /root/.john
Benchmarking: descrypt, traditional crypt(3) [DES 128/128 SSE2]... DONE
Many salts: 3772K c/s real, 3772K c/s virtual
Only one salt: 3573K c/s real, 3580K c/s virtual

Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [DES 128/128 SSE2]... DONE
Many salts: 122649 c/s real, 122649 c/s virtual
Only one salt: 119680 c/s real, 119919 c/s virtual

Benchmarking: md5crypt [MD5 32/32]... DONE
Raw: 9279 c/s real, 9279 c/s virtual

Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/32 X2]... DONE
Raw: 683 c/s real, 683 c/s virtual

Benchmarking: LM [DES 128/128 SSE2]... DONE
Raw: 48577K c/s real, 48577K c/s virtual

Benchmarking: AFS, Kerberos AFS [DES 48/64 4K MMX]... DONE
Short: 422297 c/s real, 422297 c/s virtual
Long: 1268K c/s real, 1268K c/s virtual

Benchmarking: tripcode [DES 128/128 SSE2]... DONE
Raw: 3327K c/s real, 3334K c/s virtual

Benchmarking: dummy [N/A]... DONE
Raw: 59150K c/s real, 59150K c/s virtual

Benchmarking: crypt, generic crypt(3) [?/32]... DONE
Many salts: 250867 c/s real, 250867 c/s virtual
Only one salt: 244665 c/s real, 244665 c/s virtual

Logotipo da ferramenta John "The Ripper".

Problema: Força Bruta no crypt

O crypt é o algoritmo utilizado pela maioria dos Linux para armazenar as senhas dos usuários. Segundo o comando john, o PC testado acima, consegue testar aproximadamente 250mil senhas por segundo.

A tabela abaixo demonstra o tempo para quebrar uma senha utilizando o CRYPT, dependendo do tamanho de caracteres utilizado:


Tamanho da Senha Tempo para quebrar a senha
4 caracteres 5 minutos
5 caracteres 8 horas
6 caracteres 1 mês
7 caracteres 8 anos
8 caracteres 8 Séculos
9 caracteres 74 milênios
10 caracteres 6900 milênios

Foi considerado que o usuário utilizou os caracteres imprimíveis (94 caracteres), e que letras maiúsculas e minúsculas são diferentes.
A máquina utilizada é caseira, veja que senhas pequenas são relativamente fáceis de quebrar, em até 1 mês é possível quebrar uma senha com 6 dígitos.

Conclusão

O John the Ripper é a ferramenta mais conhecida para quebrar senhas, ele possui muitas funcionalidades. O texto teve por objetivo checar quantas cifras um PC consegue gerar.
Foi observado que, dependendo do algoritmo de criptografia utilizado, o tempo muda muito. E este tempo que define a força de determinada criptografia.
No teste foi utilizado uma máquina simples, em um Cluster o tempo para quebrar seria muito inferior.
O "John the Ripper" também pode ser utilizado para testar quantas hash um servidor consegue gerar por segundo. Servidores de autenticação são os que mais realizam esta operação.

iperf: Ferramenta para testar velocidade entre duas máquinas

O IPERF é utilizado para testar a velocidade de comunicação entre duas máquinas na rede. Seu funcionamento é no modo Cliente-Servidor:
O mesmo comando é executado nas duas máquinas, mas com parâmetro diferente. No Servidor, o comando é:

iperf -s

Após o comando, o Servidor entra em modo de espera, ele aguarda a conexão de um Cliente.
No Cliente, a linha de comando fica:

iperf -c IP_SERVER

Este é o funcionamento simples do IPERF, veja o resultado:
iperf em servidor público
No caso acima, utilizei um servidor público de iperf, hospedado na França: "debit.k-net.br". A banda medida foi de 5,68 Mbits/s.

Lista de servidores públicos de Iperf 

Servidor Pais Banda
debit.k-net.fr França 1Gbits/s
iperf.it-north.net Cazaquistão 1Gbits/s
iperf.scottlinux.com USA 40Gbits/s
iperf.he.net USA 1Gbits/s

Para testar um destes Servidores públicos de iperf, basta digitar "iperf -c SERVIDOR", veja a saída de uma máquina linux com link rápido:

Iperf Servidor Público
Neste caso, a velocidade medida foi de 73,1Mbtis/s.

Instalação Iperf

O iperf funciona em Windows, Linux, Android, Apple IOS, FreeBSD, etc. Em Windows pode ser baixado no site https://iperf.fr/iperf-download.php. Em Linux, basta instalar com "apt-get install iperf".

É possível baixar o código fonte e compilar:
root@server# wget https://iperf.fr/download/source/iperf-3.1.2-source.tar.gz
root@server# tar -zxvf iperf-3.1.2-source.tar.gz
root@server# cd iperf-3.1.2 
root@server# ./configure ; make ; make install

OBS: Verifique se há nova versão no site do iperf.

Conclusão

O iperf é uma ferramenta muito simples para testar a velocidade de conexões de rede entre duas máquinas, em um determinado momento. Em testes de stress, é aconselhável utilizar ferramentas apropriada, como por exemplo o pkgen.