Identifying Web Performance bottlenecks

Web Performance

This text came about after a friend sent me a email asking if I know of a good article in Brazilian Portuguese on how to identify Web Performance bottlenecks. Unfortunately, I didn’t remember any, so then I wrote some points to get him started.

Web Performance is a vast and deep subject. If you have references, corrections or even tips, please feel free to comment here or send me a email.

Backend/Front-End

When it comes to the internet world, backend is everything that is processed by the site (web servers, databases, APIs, etc.). Front-end is everything that is processed by web browsers. This is relatively easy to identify; most site monitoring services (Syntethic monitor) use the TTFB (Time to First Byte) as part of their measurement metrics. A high value in TTFB can happen when the backend delays in delivering HTTP responses. E.g.: Dynamic pages with heavy data processing.

When internet world, backend is everything process for site (web servers, databases, APIs, etc.). Front-end is everything that process by web browsers. This is relatively easy to identify, the most site monitoring services (Syntethic monitor) use the TTFB (Time to First Byte) as part of their measurement metrics. A high value in TTFB can happen when the backend is delaying to delivery HTTP responses. E.g.: Dynamic pages with heavy data processing.

The high value of TTFB can occur when your monitoring test is far away from your site. A simple example is my site, when it was tested both in the USA and Sao Paulo.

Webpagetest - TTFB

Country Time
EUA 0,121s
Brasil 0,325s

This’s a real problem for brazilian user sites hosted in USA provides. The network latency at least 100 milliseconds, some companies prefer to clone a part of their servers architecture in Brazil to decrease the latency. So, considering latency, a good value to TTFB for Brazilian sites hosted in USA is 300 milliseconds, if the sites and users are the same region or country, the good value is +- 130 milliseconds.

the high TTFB

TTFB is a really good metric to indicate that some problem in backend, it’s a trigger to start a research to identify bottlenecks such as servers overloads, misconfiguration, slow responses of third-party APIs, bad choose of architecture definition, etc.

SSL/TLS

It’s common sense that’s good idea to provide cryptography for users sites, but few people really important to implement SSL/TLS and less yet to provide good performance when sites are using cryptography. It seems a minor stuff but it didn’t, I saw sites just to complete TLS handshake takes almost 1 second. A good value to SSL handshake is under 100 milliseconds.

TLS/SSL do Github SSL Github

TLS/SSL das listas do PostgreSQL Brasil SSL PostgreSQL Brasil

I did comparative test SSL handshake of Github homepage and mail list homepage of PostgreSQL Brasil. It’s really impressive as a good infrastructure and tweak TLS configuration can provide a good performance. Obliviously, Github was better than PostgreSQL Brasil (my fault), at last they have a lot of money. :)

DNS

Probably, DNS server is the most important network service that pay less attention. Nevertheless, it’s important to think if DNS is being a bottleneck. It’s good performance when browsers resolve DNS less 70 milliseconds. For sites with users around the world, consider use a DNS service with servers locate in more regions or countries.

DNS www.fernandoike.com

Others

TTFB can be anything, then, think about to use a FLOSS Monitoring software or even to pay someone. Really important, you need to plan what you will monitor and what metrics you will use, or you don’t want to dive in the data deep-sea without any way to rescue.

When Monitoring Service has a good implementation, it can show where are bottlenecks and many other views how your system or sites are good health.

Front-End

Even though that root case is the site infrastructure, somethings are just Identifying to analyze a web browser. Because, browsers allow whole context to open a web page and still haven’t a software that simulate exactly the browser behavior (Phamthonjs is almost there).

Compressão (gzip)

Any web server HTTP response is text/plain type, they have to be compression by gzip (RFC 2616). If you want further about this subject, read my post “CDN ranking and gzip compression (only portuguese)”. But, if you don’t time to learn portuguse or wait me write in English, below a brief note.

If Content-Type HTTP header contains any value below, consider enable compression in your web server.1

  • text/html
  • application/x-javascript
  • text/css
  • application/javascript
  • text/javascript
  • text/plain
  • text/xml
  • application/json
  • application/vnd.ms-fontobject
  • application/x-font-opentype
  • application/x-font-truetype
  • application/x-font-ttf
  • application/xml
  • font/eot
  • font/opentype
  • font/otf
  • image/svg+xml
  • image/vnd.microsoft.icon
  • text/x-js

The my site previously had a good result for compression in the Webpagetest.

Gargalos gzip - nota

Gargalos gzip - percentual

Web Browser cache (Cache-Control)

Cache-Control is a of most important HTTP header because it says to web browsers what they can do local cache or not. The most web develop frameworks provides a good management under Cache-Contol, they add the HTTP header automatically for images, javascripts, css and webfonts.

I didn’t my TLS homework this test, because my blog had a lot of third-party content (Linkedin and Slideshare). Unfortunately, they don’t use Cache-Control correctly, and this does the Repeat View isn’t good to. The Repeat View could have 40% less HTTP requests.

Repeat View

Repeat View is the second visit of user to site. E.g.: Every day I read the The Wikipedia home page to read new articles or updates.

Cache-Control HTTP Header

Third-party

Here is the most difficult to gain performance, you don’t have control of Third-party content. My website doesn’t have commercial goals, so readers of my website can be patient but users sites like ecommerces, news portal, etc. want to consume as soon as possible. As you read above, Slideshare as Third-party for my site is worst because they don’t use Cache-Control header.

There are many tricks to improve performance site for Third-party HTTP requests like defer, asynchronous HTTP requests, etc. Often have your mindset, performance and User eXperience are the most important for yours users.

Third Party HTTP Requests

Ian Murdock Legacy

Buzz I really want to know what did happen but at the moment I prefer to remember how Ian Murdock influenced me.

Inspiration Debian is a really cool name. Whenever I do a presentation about Debian, I always explain how the name came about (Debra + Ian).

Abnegation Ian Murdock could be a commercial linux distribution but he didn’t do. It’s impressive because the common sense was to create Linux distribution by a person or a very closely group. Debian was the first Linux distro to use open development; anyone could contribute to Debian. If he had founded a commercial distro, it probably would have been something like Red Hat.

Ambitious In the first The Debian Manifesto, he wrote “It is also an attempt to create a non-commercial distribution that will be able to effectively compete in the commercial market.”. Even now, to create a non-profit project to compete in the commercial market it’s a huge challenge and he did.

Kept moving forward He could have just stayed as the Debian leader, but he worked in the other projects and companies as well. At least for me, it’s really cool to always embrace new challenges and increase our knowledge.

To Beyond and infinity

10 Anos do PGBR - Listas

Logo_PGBR

O Telles lembrou dos 10 (17) anos do PostgreSQL Brasil, meus dois centavos são sobre os números das lista de discussão do PostgreSQL Brasil. Desde 2006, as listas de discussão estão hospedados em servidores dedicado.

Um levantamento rápido dos emails das listas até 2015 deu os seguintes números:

  • De 2006 à 2015 foram enviados 49.002 emails.
  • 2008 foi o ano que mais foi enviado email: 9.322
  • 2014 foi ano que menos email foi enviado: 2.523

Raking_ano

A queda de emails nas listas reflete os problemas de instalabilida que ocorrem nos últimos anos (2013-2015). Ela foi um efeito colateral da migração para contêineres (Docker), o Logrotate parava o serviço do Mailman e não conseguia reiniciá-lo. O problema ocorria porque as imagens (de contêiner) baseadas no Debian e derivados alteram a Policy-rc.d, a alteração é para que a instalação e/ou atualização de pacotes não reiniciem automaticamente os serviços. O (gambiarra) workaround foi alterar o script de rotação dos logs, removendo invoke-rc.d para /etc/init.d/comando.

Desde Agosto de 2015 às listas do PostgreSQL Brasil não tiveram mais problema de disponibilidade, reflexo disso é o aumento de emails nas listas. Também contribuiu para o aumento a conferência PostgreSQL Brasil em Porto Alegre.

Ranking_2015_mes

Para terminar este texto, um ranking dos participantes mais ativos das listas em 2015.

Ranking_top10_2015

Choosing a software name

We’re a meeting discuss how to run a tiny project. The project was a proof a concept about a new possible service and we had been think to buy a new software tool until the dialog below comes.

homerhammer

Joe: We need to prove if this idea is possible to prove is turn a good service.

Zee: Sure! I can develop a script to test it.

Joe: Then, we have to give a name to this software.

Zee: Why? It’s just a script.

Joe: C’mon, the awesome services began as a prove of the idea.

Zee: Ok, let’s we think about it.

Zee: I had a script a long time ago that I called homer.

Joe: Homer? Why?

Zee: It was lazy, unfixable and unstoppable.

Joe: Wow! Homer Hammer! Homer Hammer!

Zee: Homer Hammer?

Joe: For sure! It’s same idea but with more power devastation.

Identificando os gargalos de sites

Web Performance

Este texto nasceu de um email de um amigo perguntando se existe algum material com o básico para identificar problemas de performance (gargalos) de sites. Não lembrei de nenhum, então segue alguns itens mais básicos que podem ajudar a encontrar porque um site está lento.

Web Performance é um tema vasto e muito variado, se tiver referências, correções ou mesmo dicas, comente ou mande email. :)

Backend/Front-End

No mundo internético, Backend é tudo que é processado pelo site (servidores web, banco de dados, APIs, etc). Front-end é tudo que é processado pelo navegador web.

Isso é relativamente fácil identificar, a maioria dos serviços de testes de sites (monitoramento sintetico) usam a métrica TTFB (Time to First Byte). TTFB alto pode acontecer porque a infraestrutura do site está demorando para responder. Exemplo: Sites com páginas dinâmicas que precisam processar muita coisa para gerar a homepage de um site.

O TTFB alto também pode ser que o teste está sendo executando num local muito distante da infraestrutura do site. Exemplo disso é meu site ao ser testando no Brasil e nos EUA.

Webpagetest - TTFB

País Segundos
EUA 0,121s
Brasil 0,325s

Isso acontece porque o servidor do meu site está no EUA, um número aceitável para um site que está nos EUA e os usuários no Brasil é em torno de 300 milissegundos.

Se o site e os usuários estiverem nos EUA, o valor considerado bom é abaixo de 130 milissegundos.

TTFB alto

Pode ser várias coisas, um banco de dados com alto tempo de resposta, uma API conectada ao site terceiro, balanceador de carga com algoritimo errado, etc.

SSL/TLS

Um ponto que poucas pessoas verificam é a parte de criptografia (HTTPS). Já vi sites que o handshake de SSL/TLS para abrir a conexão HTTPS era próximo de 1 segundo, o recomendável deveria estar abaixo de 100 milissegundos.

TLS/SSL do Github SSL Github

TLS/SSL das listas do PostgreSQL Brasil SSL PostgreSQL Brasil

Incrível como no teste com o Github é rápido para fazer o handkshake SSL, contudo o mesmo teste no site das listas de discussão do PostgreSQL Brasil tem um desempenho sofrível (culpa minha!).

DNS

Parece incrível, contudo tem muito site que tem servidores DNS sofríveis em desempenho. Se a resolução DNS não for rápida (abaixo de 50 milissegundos), ele pode ser a causa do TTFB alto.

DNS www.fernandoike.com

Outros

Como comentei um pouco mais acima, qualquer parte da infraestrutura de um site pode impactar no TTFB. Se estiver desconfiado que alguma na infraestrutura do site seja o gargalo, vale à pena considerar usar alguma coisa como New Relic para instrumentar os serviços e ver o que está enfileirando.

Front-End

Ainda que a causa seja a infraestrutura do site, só é possível identificar ao analisar com um navegador web.

Compressão (gzip)

Qualquer resposta do servidor do site que for do tipo text/plain deve ser comprimida por gzip (RFC 2616). Eu escrevi um texto sobre isso no meu blog, recomendo lê-lo.

Mas estiver com pressa (imagino que sim!), basicamente é o seguinte: se na resposta HTTP tiver o cabeçalho Content-Type com algum dos valores abaixo, deve-se considerar habilitar a compressão.

  • text/html
  • application/x-javascript
  • text/css
  • application/javascript
  • text/javascript
  • text/plain
  • text/xml
  • application/json
  • application/vnd.ms-fontobject
  • application/x-font-opentype
  • application/x-font-truetype
  • application/x-font-ttf
  • application/xml
  • font/eot
  • font/opentype
  • font/otf
  • image/svg+xml
  • image/vnd.microsoft.icon
  • text/x-js

O meu site (no momento) está com um bom desempenho para compressão no Webpagetest.

Gargalos gzip - nota

Gargalos gzip - percentual

Cache no navegador web (Cache-Control)

O cabeçalho Cache-Control diz para o navegador web o que ele pode ou não cachear. O bom uso dele faz com que o site tenha um consumo menor de banda de rede. É muito comum usá-lo para fazer cache de imagens, javascripts, css e fontes no navegador web.

O meu site não faz o bom uso dele no teste que fiz no Webpagetest. Ao abrir o link abaixo você verá que a pontuação é baixa porque meu site usa conteúdo de terceiros (Linkedin e Slideshare), eles infelizmente não usam o Cache-Control.

Ainda usando meu site como exemplo, se o Cache-Control fosse bem usado, a quantidade de requisições (request) HTTP no Repeat View seria bem menor. O Repeat View no meu blog tem 23 e ao menos deveria ser em abaixo de 40%.

Repeat View

Simula o acesso de navegador web com parte do conteúdo cacheado pelo computador do usuário, seria como se o usuário acesse o site pela segunda vez.

Cache-Control HTTP Header

Terceiros

Muitos sites usam conteúdo de terceiros nas suas páginas, geralmente conteúdo de redes sociais ou publicidade. Esse conteúdo por impactar no desempenho do site significativamente se for abusado o uso dele.

Meu site tem mais requisições do Slideshare do que dele próprio, portanto, meu site é totalmente dependente do desempenho do Slideshare para ser rápido para usuário. Existem algumas formas de contornar usando coisas como defer.

Como não vivo do site, posso conviver mas sites que são ecommerce ou portais de notícia não podem conviver com esse “gargalo”, precisam fazer que o as requisições HTTP para terceiros (parceiros) sejam feitas depois que Document Complete (ou o evento Onload) esteja concluído.

Third Party HTTP Requests

Building Debian images by jigdo

A friend asked me how to got a Debian Old Image, she wanted to download Debian Squeeze DVD image. Unfortunately, it’s impossible to download by Debian-CD mirror because Squeeze isn’t more maintainer. So, it’s possible to get a Image by Debian-CD primary server but it’s locate in Sweden. Nothing problem, right? Well, She lives in Brazil and the download time is a little bit more than 8 hours.

A good tool to “download” a Debian image is the Jigdo. It’s a program to synchronize repositories and generate Images. It get packages and build a image locally in your computer.

I made a simple test, I used jigdo to “download” the first Squeeze DVD by brazilian repository (Unicamp) and compare with a download image by PR (Primary Server). The difference was huge, PS download took a long time to finish (8 hours) and Unicamp mirror finished in 100 minutes.

Well, let’s go to practice.

Install jigdo

#aptitude install jigdo

Downloading and building image

The jigdo file (.jigdo) is simple list with all packages and hash of a instalation image. You need it to start the downloads. In this case, I used jigdo file to build first Squeeze DVD.

$jigdo-lite http://cdimage.debian.org/cdimage/archive/6.0.10/amd64/jigdo-dvd/debian-6.0.10-amd64-DVD-1.jigdo

Before to begin download, jidgo need some arguments. Fill arguments of your preference but remember that the argument more important is the mirror. If you have doubt what’s mirror is more fast, you can use netselect-apt to discovery. For my test, I’m used Unicamp mirror (http://debian.las.ic.unicamp.br/debian).

My jigdo-lite conf file.


$cat ~/.jigdo-lite
-------
jigdo=''
debianMirror='http://debian.las.ic.unicamp.br/debian/'
nonusMirror=''
tmpDir='.'
jigdoOpts='--cache jigdo-file-cache.db'
wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30'
scanMenu='

Nice, huh?

Take a coffee and forget to download Debian images using others programs (curl, wget, etc.). :)

FISL 16

fisl16.png

FISL 16 aconteceu algumas semanas atrás… e depois de nem tão rigoroso inverno consegui rascunhar alguma coisas sobre o evento.

Impressões

Como sempre, sempre bom rever os amigos e conhecidos de inúmero projetos que participam. O evento não estava tão lotado como nos últimos anos que participei mas mesmo sim acredito que teve um bom público.

A internet até que funcionou razoavelmente bem, o wifi do evento era usável a maior parte do tempo e também gostei das palestras que assisti. Curti demais participar da Mini-Debconf realizada durante o FISL, fico feliz que em 2015 no Brasil serão (no mínimo) 3 Micro/Mini-Debconf. :)

As minhas apresentações

Este ano fiz duas apresentações no FISL16, uma sobre Web Performance e a outra sobre Management 3.0. A apresentação de de Web Performance foi a última vez que apresentei (acho), fiz algumas pequenas atualizações e acréscimo de exemplos que a deixou com +- 100 lâminas (slides). Já tem material suficiente para escrever um livro (quem sabe…). ;)

A apresentação sobre Management 3.0 é sobre como foi descobrir que usamos (equipe de TI que participei) esse conceito antes de saber que existiu um nome. Eu descobri Management 3.0 depois de participar de um curso de Scrum com Manoel Pimentel, isso foi alguns anos depois que já não era mais gerente. Ele me ajudou bastante para avaliar os erros e acertos como gerente. Recomendo para quem se interessar desempenhar o papel de líder de equipe ou chefia a estudar um pouco mais sobre tema.

Um milhão de usuários simultâneos

Um milhao de usuários simultâneos

O vídeo da apresentação pode ser acessado por aqui e aqui.

Management 3.0

Management 3.0 - a vida pós-agilidade

O vídeo da apresentação pode ser acessado por aqui.

Eventos em maio de 2015

Essa semana estarei participando de dois eventos como palestrante.

Devcamp

O Devcamp é a “A maior conferência de desenvolvimento de software do interior São Paulo” e esterei apresentando sobre a minha experiência em migrar para Docker. Docker é novo buzzword um projeto de automação de deploys de aplicações dentro de contêineres. Se estiver por lá e quiser tomar um café, estarei a disposição.

Meetup Germinadora

Provavelmente é a última vez que apresente essa palestra sobre Web Performance (“Um milhão de usuários simultâneos”). Não que eu não goste de falar sobre o tema, pelo contrário (gosto bastante)! Tem algumas partes específicas dessa apresentação que quero abordar numa próxima vez.

Se estiver de bobeira por aqui em São Paulo, passe por lá.

Docker 1 dot 6 lancado

O lançamento da versão 1.6 veio com boas novidades, algumas delas são do ecossistema mas cabe destacar: Docker Compose, Docker Machine e o Registry. O Compose é o antigo Fig, ele facilita bastante se você trabalho com sistemas em múltiplos containers. O Machine permite criar uma infraestrutura Docker rapidamente, seja numa máquina virtual (exemplo: Virtualbox) ou mesmo numa IaaS (AWS, Digital Ocean, etc.).

As funcionalidades da versão 1.6 que gostei foram:

Suporte a Image Labels

No Dockerfile pode adicionar um campo extra para usar como identificação sua. Isso permite pesquisar informações de containers e imagens usando esse campo.

Logging Drivers

Ficou bem mais fácil enviar os logs para um Syslog ou similares. Muita gente tem dificuldade de lidar com os logs do container até essa versão.

  • Alterar as imagens de containers sem recriá-las A partir desta versão é possível alterar algumas coisas numa imagem de container sem a necessidade de gerar novamente.

Ulimit

A minha favorita, agora é possível alterar alguns parâmetros do ulimit, bom para serviços que usam muito processos como banco de dados.

Para saber mais, acesse o blog do Docker que tem mais informações.

Obs.: Ah, a versão 1.6 está na Experimental no Debian e infezlimente não entrou na Jessie, mas logo estará disponível no Backports.

Obs.2: O original dessa imagem é do blog do Docker.

Debian Jessie 8 lancado

O Debian continua executando o plano de dominação do universo. As duas novidades é que a eleição do novo líder do projeto, Neil McGovern, após dois mandatos do Lucas Nussbaum.

A outra novidade é que nova versão estável (Jessie) do Debian foi lançada no dia 25 de Abril de 2015 com a narração da mudança do Wheezy para a Jessie. Se quiser ver como foi o lançamento, use a hashgtag #releasingjessie

São 75 idiomas suportadas na instalação, systemd como sistema de inicialização padrão, MySQL, MariaDB, Samba 4.1, PostgreSQL 9.4, etc. São mais de 43 mil pacotes a partir de 21 mil (pacotes) fonte. Suporte a numa nova arquitetura (ARM64). O tempo de freezing desta versão foi relativamente curto, 171 dias.

Pouco? Bom, o restante das novidades você pode ler mais [aqui][debianews].

Quem diria?

Nos anos que trabalhei como consultor de tecnologias em software livre/código aberto, era muito difícil integrar ou substituir sistemas proprietários. Principalmente nos casos de servidores, storages e/ou equipamento de backups.

O trabalho maior não era o técnico, era de reverter o marketing negativo. Coisas como: “Não tem licença, como é que você irá acreditar numa empresa que não é dona do produto”, “A comunidade vai dar suporte? Fica esperando, então!“, “O fornecedor de hardware não suporta o Debian, se quiser use uma distribuição comercial”, “Um Sistema Operacional que só usa tela preta? Isso é anos 80!”

Depois de alguns e bons anos o que mudou? Muita coisa, tanto que a Microsoft participou das festas de lançamento da Jessie.