Tim Berners-Lee. Decepção proporcional à expectativa

Desde o dia que soube que teria a oportunidade de participar deste fantástico evento, o www2013, que reúne os papas da Internet e este ano seria no Rio de Janeiro, fiquei muito empolgado. Particularmente pelo fato que poderia conhecer nada mais nada menos do que o inventor da web, Tim Berners-Lee.

Minha expectativa era grande para ouvir o que tinha a dizer sobre o futuro da Internet alguém que, simplesmente criou o www e com isso revolucionou a rede.

 Aguardei ansiosamente. Primeiro, o dia que estava marcado para ele falar. Depois o momento. Mas então o inimaginável aconteceu. A palestra de Tim Berners-Lee se baseou em torno de algo conhecido como DRM (Digital Rights Management). Sim... O inventor da web, de quem se esperava uma visão mais libertária, por uma Internet mais aberta, flexível, veio falar de um padrão de gerenciamento de copyright. 

O DRM é uma tecnologia que permite aos donos dos direitos autorais de um determinado conteúdo - video, música, texto, etc., controlar o conteúdo fornecido, mesmo após a venda ter sido concluída. Basicamente é como se, depois que um consumidor comprasse um CD, por exemplo, a gravadora pudesse decidir o que ele vai fazer com o material. Em outras palavras, o DRM aumenta ainda mais o poder da indústria sobre o consumidor.

Quem entende de tecnologia deu sua opinião: O DRM não vai funcionar. Ele é péssimo em evitar quebra de direitos autorais, mas é muito eficiente em impedir a inovação.

Tim Berners-Lee, defendeu a incorporação do DRM ao HTML5.

A sensação durante a palestra era de incredulidade. Quando abriram para perguntas da platéia à Tim, foi uma grande confusão. Como esperado, houve polêmica e as perguntas foram bem longas. Todos queriam saber o motivo que levou o criador da web a defender uma posição tão conservadora.

Afinal, o mundo discute, desde o advento do Napster, a possibilidade de uma nova forma de relação consumidor x indústria, do conteúdo "protegido" por direitos autorais. Até onde a gravadora, por exemplo, não esteve abusando de sua posição? Sabemos que o artista leva apenas uma pequena parte na divisão do bolo. E o consumidor paga caro. Então, uma discussão que vinha sendo saudável, voltou ao ponto de partida? Agora sob o aval do criador da web?

Ao sair da palestra comentei com amigos minha impressão. Acharam que eu estava exagerando. Mais tarde, ao conversar com outros presentes, minha opinião se mostrou correta. A palestra com Tim foi a grande decepção do evento.

Quinta-feira na www2013 - Um dia de altos e baixos

A quinta-feira foi marcada pela excelente apresentação do neurocientista brasileiro Miguel Nicolelis. O leitor certamente se lembrará de uma reportagem do Jornal Nacional que mostrava dois ratinhos cujos cérebros foram conectados por eletrodos, um em Natal/Rio Grande do Norte, e o outro na Carolina do Norte, nos Estados Unidos. Dr. Miguel é nada mais nada menos do que o cientista responsável por este projeto.

Ele nos explicou que as pesquisas estão permitindo descobertas fantásticas sobre o cérebro. Hoje sabe-se, por exemplo, que o cérebro está muito ligado ao contexto externo que lhe é apresentado como realidade, e que se adapta rapidamente a qualquer mudança de contexto, podendo rearrumar-se para funcionar da melhor maneira possível.

Inclusive, afirmou que estamos evoluindo enquanto seres humanos em função da expansão que a vida moderna, em particular a Internet, está causando em nossos cérebros. Disse que a evolução genética está perdendo para a evolução de expansão do contexto cerebral.

No caso dos dois ratos cujos cérebros foram conectados, os dois animais trabalharam em cooperação para resolver determinadas tarefas. Dr.Miguel explicou que um dos ratos era o codificador e o outro o decodificador. E que é provável que o decodificador tenha a sensação de sentir o corpo do outro como uma extensão do seu próprio corpo. Assim, um estímulo nos bigodes do primeiro rato (e o rato usa os bigodes para tatear o meio onde circula) é percebido pelo segundo rato como se fossem seus próprios bigodes. Portanto, é como se o segundo rato estivesse vestindo o corpo do primeiro, virtualmente.

Dr.Miguel também nos apresentou um projeto chamado "The Walk Again Project" (http://www.walkagainproject.org/), cujo objetivo é construir uma espécie de protese, um tipo de exoesqueleto que um ser humano desprovido de locomoção poderia vestir e controlar como o próprio cérebro, tornando-se uma espécie de ciborgue. O aparato enviaria informações de feedback para o cérebro do usuário, de forma que a experiência melhoraria continuamente, até que o objeto fosse totalmente integrado ao contexto do cérebro como uma parte integrante do corpo da pessoa. Para o cérebro não faz diferença.

Dr.Miguel contou que sugeriu à presidente da  república que na abertura da copa do mundo de 2014, um cadeirante usuário do dispositivo aparecesse no meio de campo do gramado, levantasse de sua cadeira de rodas sozinho, caminhasse até uma bola de futebol e a chutasse.

Na minha opinião é brilhante, enaltece a ciência brasileira, enche de esperança aqueles que como eu gostariam que coisas importantes fossem valorizadas no país. Essa idéia é muito, muito melhor do que apresentar crianças batendo latas ou um gari famoso dançando sorridente. Faz muito mais sentido. Ele apresentou um video com uma animação gráfica em 3D demonstrando como seria. Confesso que essa parte da palestra me emocionou. São poucos os momentos que vemos coisas assim acontecendo no Brasil.

A palestra do Dr. Miguel, enfim, encantou a todos na platéia, mostrou que a ciência bem direcionada pode sim mudar o ser humano e o dia a dia na vida das pessoas. Antigos sonhos foram reavivados aqui. Imagine poder fazer pessoas deficientes físicas recuperarem suas funcionalidades. E isso tudo liderado por um brasileiro! Simplesmente o máximo.

Algo que ele também mencionou e que acho que vale o comentário é que o cérebro, apesar de controlar toda a parte sensorial do organismo e administrar o reflexo da dor, por exemplo, ele próprio não sente dor. Uma pessoa ou animal que tem seu crânio aberto e seu cérebro operado, simplesmente não percebe dor quando o objeto manipulado é o próprio cérebro.

Apesar da euforia provocada pela primeira palestra, a que se seguiu foi motivo de polêmica. O tão aguardado keynote speaker Tim Berners-Lee, inventor da web, meio que decepcionou - pelo menos a mim. Será o assunto do meu próximo post.

Até breve.

www2013 - Luis von Ahn - Genial! (atualizado às 11:48)

Esta semana estou tendo a honra de participar do evento www2013, encontro mundial que acontece uma vez por ano em diversas cidades no mundo e este ano é no Rio, no hotel Windsor Barra. Basicamente é uma conferência com os grandes players da Internet, contando sempre com a participação do W3C, o consórcio internacional liderado por Tim Berners-Lee que cria os padrões da Internet.

Apesar do evento ter tido início na segunda-feira dia 13, a cerimônia oficial de abertura ocorreu ontem, quarta-feira e foi onde tivemos a primeira palestra dos esperados keynote speakers. Na ocasião quem falou foi Luis von Ahn e foi simplesmente genial!

Luis von Ahn é natural da Guatemala, um jovem empreendedor de 34 anos. Iniciou sua apresentação contando-nos que quando criança seu grande sonho era criar uma academia onde as pessoas gerariam eletricidade durante a prática de exercícios físicos. Assim, ao se exercitar em uma bicicleta, esteira ou aparelho de musculação, a pessoa estaria simultaneamente gerando energia. As pessoas poderiam frequentar o estabelecimento sem custo. E em contrapartida a energia gerada nos exercícios seria vendida à companhia de energia da cidade.

Luis se tornou um adulto mas o modelo de negócio não se estabeleceu. No entanto, o cerne de sua idéia (que poderíamos chamar de colaboração trocada), permaneceu vivo e ele começou a utilizá-lo em seus novos projetos.

Um dia, ao se inscrever em um site de relacionamento e enquanto digitava os caracteres de um campo de confirmação "captcha" para garantir ao site que um humano estava se cadastrando, ele não pode deixar de pensar no tempo que as pessoas perdem na vida digitando captchas. Fez alguns cálculos e, levando em conta que geramente alguém leva 10 segundos para digitar um captcha, chegou a conclusão que várias horas de trabalho humano são gastas nesta atividade quase inútil, que não acrescenta nada em nossas vidas e só existe para evitar a ação de má-fé de terceiros contra sites.

E foi então que, bingo! Por que não aproveitar o trabalho de digitação de captchas para uma atividade mais nobre? E eis que ele criou o "reCaptcha" - um sistema de digitalização de livros a partir da digitação de captchas nos sites mundo afora.

O que acontece é que hoje em dia, imagens com trechos de livros que não puderam ser digitalizados por softwares de reconhecimento de caracteres são utilizados nos captchas de diversos sites. E ao digitar os caracteres dos mesmos as pessoas estão contribuindo com a digitalização de um livro, ainda que não estejam cientes disso.

Luis também falou que nos EUA há empresas que contratam (e pagam) pessoas para digitar captchas, no intuito de burlá-los. Há muita gente interessada nisso, via de regra spammers. Ao invés de ser uma preocupação para Luis, isso representa para ele um valor adicional: No pior dos casos, além de mais gente contribuindo para a digitalização, ainda há a geração de emprego.

Genial! Já estaria de bom tamanho, mas Luis não parou por aí. Devido a sua origem, vindo de um país pobre da América Central, a Guatemala ele não podia deixar de pensar em algo que permitisse equalizar financeiramente a vida das pessoas. E ele percebeu que muitas pessoas na Guatemala gostariam de aprender uma língua estrangeira, se tivessem condição, pois é uma forma de crescer financeiramente na vida - saber outras línguas.

Luis explicou à platéia que é raríssimo um americano ter vontade de aprender uma língua estrangeira. E quando o faz é porque vai viajar. Então estuda francês para uma viagem à Paris, ou espanhol se vai visitar a América do Sul. Mas geralmente se trata de uma curiosidade.

Por outro lado, as pessoas fora dos EUA aprendem uma língua estrangeira (e geralmente o inglês), como uma forma de aumentar suas chances de empregabilidade, ou seja, está mais ligado à sobrevivência (isso para os americanos é um fato ignorado).

Ocorre que aprender línguas custa dinheiro. Como resolver o problema?

Em mais uma de suas criações geniais, Luis von Ahn fez o "Duolingo" - Um site de ensino de línguas onde a pessoa estuda de graça, mas todos os exercícios de tradução que ela faz são aproveitados por empresas que estejam precisando traduzir alguma coisa.

Ele provou que a tradução é muito mais barata do que se profissionais fossem contratados para isso, muito melhor do que a tradução feita por máquinas e o resultado final é de qualidade equivalente a uma tradução feita por profissionais.

Enfim, a fundamentação de suas idéias - a colaboração cruzada - é uma jogada simplesmente genial. Assisti a muitas outras palestras esses dias, que mostravam técnicas e conceitos extremamente complexos, mas no final das contas, as idéias mais óbvias são as que mais modificam o mundo.

Fazendo uma analogia com o que tive o prazer de aprender no curso de inovação com o consultor Carlos Nepomuceno (http://nepo.com.br) sobre colaboração, acredito que este é um capítulo novo nessa história.

Fico pensando onde mais poderíamos utilizar essa prática no nosso dia a dia para mudar o mundo para melhor, de maneira ainda mais eficiente.

Aguardem novidades sobre o evento!

Uma abordagem revolucionária no uso do QR Code

Embora amplamente utilizado em embalagens de produtos nas prateleiras dos supermercados, em páginas de revistas semanais, outdoors, videos de lançamentos imobiliários, guias turísticos, etc., o QR Code ainda é um desconhecido para grande parte das pessoas.

O QR Code é um código de barras em preto e branco e em duas dimensões. Foi desenvolvido para ser veiculado em mídia impressa, com o objetivo de levar o leitor a um endereço web. Dessa forma, o interessado pode obter maiores informações sobre aquilo que lhe chamou a atenção.

O QR Code é lido pela câmera de telefones celulares. Qualquer smartphone genérico hoje em dia já vem com um aplicativo que lê esse tipo de código de barras (o famoso bar code scanner app).

Um QR Code na embalagem de um produto, por exemplo, pode levar o consumidor a um site que descreve as características do mesmo, mostra um histórico da empresa, a forma como ele foi produzido, onde obtém sua matéria-prima, enfim, um local onde o consumidor pode aprofundar seu conhecimento sobre o que está comprando.

Em alguns casos, pode-se comprar o produto pelo QR Code, por exemplo, pedir uma pizza através de um panfleto da pizzaria entregue no escaninho do correio já é possível em alguns países.

Alguns monumentos históricos têm QR Codes impressos em placas informativas, através dos quais as pessoas obtém dados extras sobre aquele ponto turístico.

As opções de uso são vastas. Mas todas têm em comum levar alguém do mundo real, físico, para o mundo virtual, isto é, fazer uma pessoa acessar um website que tenha relação com aquilo que está se vendo.

Em uma pesquisa rápida no Google, é fácil encontrar listas de usos criativos para o QR Code. Mas via de regra, é conselho comum não utilizar o QR Code em meio eletrônico, pois isto estaria indo de encontro ao seu objetivo primordial. 

Por quê mostrar um QR Code em meio eletrônico, se o objetivo é justamente levar o usuário para lá? Ele já está lá. Então considera-se que não há sentido nesta abordagem.

Mas... Não tem aquela coisa de "pensar fora da caixinha"? E se o QR Code fosse utilizado para levar a um link, não de uma página de website, mas de um arquivo para download?

Dessa forma, ao apontar a câmera do celular para a tela do computador, um arquivo seria automaticamente transferido para o aparelho. Isso causa uma curiosa sensação de que o arquivo está "pulando" do monitor para o celular.  Mas a revolução não é apenas esta.

Imagine links que geram relatórios em PDF ou documentos do Office, estatísticas, ou consolidação de dados, enfim, qualquer produto destinado ao usuário final. Através do uso desta tecnologia do QR Code aliada a sistemas web e banco de dados, é possível agora oferecer ao nosso cliente, consulta às informações sem nem ao menos logar em um sistema.

É como se estivéssemos levando os dados para "caminhar lá fora". Quebrando os limites físicos entre os dados e o usuário final, consumidor da informação.

Um usuário poderia abrir uma planilha excel em seu celular, apontando a camera do mesmo para um QR Code, até mesmo impresso.

Espectadores de uma palestra poderiam obter a apresentação do palestrante imediatamente durante o evento, ao apontarem seus smartphones para o QR Code no telão do projetor.

A imaginação aqui é o limite. Com um pouco de criatividade é possível inventar usos totalmente inéditos para esta idéia inovadora.


O funcionamento seria algo como o ilustrado na figura:

Penso que estamos diante de uma quebra de paradigma aqui. A idéia explicitada abre caminho para uma abordagem totalmente diferente no desenvolvimento de sistemas, possibilitando ao usuário consumir a informação sem a necessidade de uma interface gráfica.  Dessa forma, estaria-se criando uma nova maneira de relacionamento na ciência da informação.

Poderia-se oferecer ao usuário uma espécie de cardápio, onde estariam impressos os QR Codes, todos com seu operacional devidamente identificados por subtítulos, por exemplo: Relação de edifícios no centro com acessibilidade, gráfico comparativo de resultados trimestrais, apresentação do funcionário João Silva, lista de contatos da empresa.

Sobre este último exemplo da lista de contatos, destaco especial atenção ao fato de que seria possível aliar essa nova abordagem a um trabalho colaborativo. Dessa forma as informações que fossem sendo produzidas aos poucos por muitos funcionários dando entrada nos sistemas de dados, gerariam um produto consolidado, que poderia ser consumido por todos na empresa.

Podemos usar esta idéia para mudar para melhor radicalmente a maneira como trabalhamos, produzimos e também a forma como nossos clientes consomem nossos produtos.

O papa-filas e o round-robin de DNS...

Dando seqüência ao tema "balanceamento de carga", vou agora mostrar os tipos mais comuns e suas vantagens e desvantagens, de forma a suprir o leitor com subsídios para uma escolha adequada ao seu caso.

1) Balanceamento por Round-Robin de DNS

O algoritmo de "round-robin" não é nenhuma novidade para profissionais de informática. Em qualquer curso de faculdade ele é assunto freqüente.  É simplesmente uma lista, enfileirada, em que os elementos vão, um a um, assumindo certa posição. Ao chegar no último elemento, o processo reinicia com o primeiro elemento. O DNS (Domain Name System) é uma forma de traduzir endereços de sites em seus respectivos IPs, por exemplo: www.google.com.br vira 74.125.234.159. O balanceamento de carga via round-robin de DNS funciona redirecionando alternadamente o usuário para uma lista de servidores, cada vez que ele acessa a mesma URL pelo navegador. Ou seja, há mais de um IP respondendo a uma mesma URL, só que de forma alternada.

Funciona de maneira muito similar ao "papa-filas" do supermercado, onde cada cliente entra numa única fila e ao final é direcionado para uma das gôndolas de pagamento disponíveis.

Se forem três servidores de aplicação, cada vez que o usuário recarregar a página no navegador, será direcionado para um dos servidores. Se chegar no último servidor e recarregar a página, será redirecionado novamente ao primeiro servidor.

Essa é uma forma bastante simples de balanceamento, que não leva em consideração a carga de cada servidor de aplicação, ou seja, não é um balanceamento ótimo, porque uma máquina lotada vai continuar recebendo usuários. Além disso, caso uma das máquinas falhe e fique fora do ar, ela mesmo assim ainda estará participando da fila. E usuários serão redirecionados para ela assim mesmo, recebendo a mensagem de que o servidor está fora do ar. Em outras palavras, um certo grupo de usuários cairá na máquina que está ruim.

Apesar das desvantagens, é uma forma extremamente fácil de implementar e é recomendável que ela exista em conjunto com outras formas de balanceamento.

No próximo post falarei sobre balanceamento de carga por cluster.

Quantidade pode ser melhor que qualidade? Entenda como funciona o balanceamento de carga.

Há alguns anos atrás, participei de um projeto de um sistema que tinha uma previsão de alto número de usuários simultaneos pela rede. Sugeri ao líder do projeto que fizesse um grupo de servidores de aplicação, fazendo balanceamento de carga entre eles, ou seja, montar um conjunto de dois ou mais computadores rodando a mesma aplicação, que dividissem o trabalho de atender àqueles usuários do serviço.

 

O líder do projeto não adotou a sugestão, argumentando que "tínhamos um servidor parrudo", com muita memória e vários processadores, capaz de suportar tamanha demanda. Contra-argumentei que, apesar de toda a indubitável capacidade do servidor, ele era um só. E se falhasse, o sistema ficaria fora do ar.

 

Mas, infelizmente, o líder do projeto não tinha visão orientada à otimização. E disse que o que deveríamos fazer era preparar um servidor de contingência. A visão dele era assim: "Temos um servidor que aguenta o tranco. Mas, no caso de não aguentar, colocamos outro, igual, para assumir a questão".

 

O resultado da história foi que o sistema foi posto no ar dessa forma. E o tal servidor "parrudo", à medida que o número de usuários aumentava, foi ficando lento, lento.... Até que chegou uma hora que o sistema caiu. E foi aquela correria! Inicialmente reinicializou-se o servidor várias vezes, mas os usuários retornavam (obviamente) e o sistema caía de novo.

 

Ligou-se a contingência. Ficou assim: O primeiro servidor entrava no ar. Os usuários acessavam o sistema, até que ele caía. Aí os próximos usuários eram direcionados ao segundo servidor, que também entupia e caía.

 

O tal líder do projeto culpou a tudo e a todos. Disse que o sistema operacional não prestava, reclamou do software do servidor de aplicação, da linguagem em que foi desenvolvido o sistema, maldisse o fabricante dos processadores do servidor, enfim, criou uma porção de desculpas para a coisa não ter funcionado. Mas em nenhum momento cogitou a hipótese de estar errado.

 

Sua vontade era reescrever o sistema em outra linguagem, funcionando sob outro sistema operacional, mas permanecendo o ambiente de um único servidor com outro de contingência.

 

Ele tinha o apoio da empresa, que confiava na sua competência técnica. E realmente ele tinha muita competência técnica, inegavelmente. Mas lhe faltava algo de igual importância: Maturidade.

 

Bem, o sistema ia pro ar uma vez por ano. Durante dois anos permaneceu assim. Funcionava mal, os usuários tinham uma péssima experiência e havia um alto nível de estresse.

 

Finalmente, o líder do projeto decidiu começar a buscar otimizar o sistema e isso promoveu uma certa melhora. Mas ele ainda não havia sido convencido da necessidade de dois ou mais servidores.

 

Em um belo dia de sol, mudaram o líder do projeto. Eu permaneci no grupo de desenvolvedores do sistema. Após uma longa conversa com a nova líder do projeto, consegui convencê-la da importância de ter um modelo com dois ou mais servidores de aplicação, ao invés do modelo de servidor+contingência.

 

Infelizmente a empresa foi contra. Então, junto com um colega de equipe, montamos um cluster de servidores de aplicação, utilizando máquinas velhas do nosso setor, abandonadas, cacarecos mesmo, mas fazendo balanceamento de carga. Fizemos testes então, com softwares que simulam acessos simultâneos de usuários, sobre nosso cluster de cacarecos. E... adivinhe? A estabilidade era maior do que em uma situação de um único "servidor parrudo".

 

Os dados eram incontestáveis e foi o argumento que convenceu a empresa a adotar tal procedimento. Hoje em dia todo sistema da empresa que precise de alto desempenho e disponibilidade utiliza mais de um servidor, em cluster (usamos várias máquinas virtuais, fazendo balanceamento).
 

Eis um caso em que quantidade é melhor do que qualidade.

 

No próximo post aprofundarei este tema, mostrando os tipos de balanceamento de carga possíveis de implementar. Não perca!

O que o xadrez de rua tem a ver com sistemas rápidos?

A técnica que vou ensinar neste post - e é uma das mais recentes utilizadas em nossos sistemas, embora não seja nenhuma novidade - chama-se "query simulada".

Mas antes vou falar sobre um filme que assisti há alguns anos atrás, chamado "Lances Inocentes" (Searching for Bobby Fischer).

 

O filme conta a história de um garoto que tem um talento especial para o xadrez e é incentivado pelo pai a participar de competições. A família do menino contrata um instrutor que passa a treiná-lo sob uma abordagem clássica do xadrez. Só que simultaneamente, o garoto conhece um enxadrista de rua, que também o influencia, mas sob a ótica do "speed chess", com técnicas bastante heterodoxas, consideradas pelo instrutor do menino como de segunda categoria. E instala-se o conflito.

 

Mas o que, afinal, tem a ver o xadrez de rua com sistemas rápidos?

 

Bem, no contexto de sistemas, sempre existiu uma discussão sobre boas práticas de programação. Há um conflito entre o meio acadêmico e quem "põe a mão na massa".

 

Nesse contexto, todos sabemos que colocar informações hard-coded no sistema (junto com o código-fonte) é uma prática péssima de programação, certo?

 

Bem, o enxadrista de rua do filme tinha seu ponto de vista. E sua técnica funcionava em determinadas ocasiões. E ajudou o menino a encontrar um meio termo.

 

Portanto, estou dizendo que tudo na vida depende do contexto. Em uma situação em que a velocidade de resposta é condição sine qua non, aceito sim ser um pouco heterodoxo.

 

Isto posto, vamos ao que interessa: O que afinal é uma "query simulada"?

 

De forma simples, é programar o resultado de uma query hard-coded no sistema. Posso dizer que é uma espécie "query cacheada" que não expira e que ocupa a memória pontualmente, por pouco tempo. A vantagem não podia ser outra: Velocidade, disponibilidade, menor probabilidade de falhas.

 

Fazemos isso pegando um método que retorna uma query real, indo efetivamente ao banco de dados, substituindo-a por uma query simulada. Para o resto do sistema, é como se estivéssemos indo realmente ao banco de dados. O retorno continua sendo um recordset, mas nós o preenchemos manualmente e o sistema é induzido a acreditar que os dados vieram mesmo do banco. E não tem mesmo diferença nenhuma.

 

Essa foi uma forma de otimizarmos ainda mais o que já havia sido otimizado em nossos sistemas.

 

Estudamos as queries elegíveis para "query simulada" e as convertemos, é claro, com muito critério.

 

Como exemplo, imagine uma query que vai ao banco de dados obter os estados federativos brasileiros e que é muito utilizada. É possível criar uma query fake no sistema que contenha a lista dos estados. O acesso é infinitamente mais rápido do que indo ao banco. Evita tráfego de rede, vai continuar mostrando os estados mesmo que o banco esteja fora do ar, enfim, no contexto de um sistema que não pode ter gargalos, é uma técnica a mais no rol das possibilidades., e que não deve ser ignorada.

Fique ligado que ainda tem muito mais pela frente! Até o próximo post.

Outro pulo do gato: O query timeout!

Caros leitores, hoje falarei sobre algo não menos importante do que o assunto tratado no post anterior. Considero que é também outro "pulo-do-gato" em se tratando de otimização de sistemas web: O "timeout de query"!

 

Tomando-se a velha premissa como base, ou seja, que o banco de dados é um recurso finito, disputado, e portanto sujeito a falhas, e considerando que uma query pode levar mais tempo do que o desejado para executar, então faz-se necessário o uso do "timeout de query".

 

A questão é que, se uma query demorar muito para retornar um resultado, o servidor de aplicação enfileirará requisições, o que é nosso maior temor - e deve ser evitado a qualquer custo.

 

O "timeout de query" funciona de forma muito similar ao "cache de queries". Mas, o intuito aqui é especificar um tempo que nossa aplicação considerará aceitável para a execução de uma query.

 

Em cada query do sistema, especifica-se em segundos, o tempo que aceitaremos para sua execução. Caso esse tempo seja atingido, o servidor de aplicação considerará que houve uma exceção. Um erro, provocado por estouro de tempo limite na execução da query.

 

Esse erro deve ser esperado e tratado pela nossa aplicação, que, em geral, informará ao usuário que a sua requisição não foi atendida dentro do tempo esperado.

 

A grande vantagem é que o usuário não tem a percepção de um sistema lento, agarrado, pelo contrário, para ele a aplicação continua no ar e respondendo adequadamente. Só que agora informando o que ocorreu e permitindo que ele tente novamente.

 

Sendo um dos grandes segredos de um sistema web estável e com alto uptime, o "query timeout" é  uma prática indispensável. Todas as queries do sistema devem utilizá-lo, sem exceção!

 

Até a próxima!

Eis o grande segredo...

Hoje vou falar sobre uma das formas mais eficazes de otimização de qualquer sistema web: Apresento-lhes o "Cache de Queries".

No post anterior, discerni sobre a importância da otimização do banco de dados e sobre a preocupação que se deve ter com o tempo de execução de cada uma das queries que fazem parte de um sistema.

Portanto, o banco de dados é o ponto de maior geração indireta de gargalos em um sistema web. Se ele estiver lento, todo o resto ficará lento, através de um efeito cascata. O acesso ao banco é o maior problema.

Vamos então "eliminar o problema".

"Mas como assim? Afinal o banco de dados é o cerne do sistema. Sem ele não faria sentido o sistema!" - já ouço o leitor retrucar.

Na verdade, não estamos falando, obviamente, em eliminar o banco de dados. Estamos falando em evitá-lo o máximo que pudermos!

Quanto menor for o número de vezes que a aplicação precisar "encostar" no banco de dados, melhor para a performance geral do sistema web.

E é isso exatamente o que faz o Cache de Queries! Evita "idas" desnecessárias ao banco de dados!

O Cache de Queries é algo realmente modificador de vidas. Eu diria que um sistema pode ser dividido entre antes e depois da implementação de Cache de Queries.

O Cache de Queries funciona da seguinte maneira: Você especifica deliberadamente que uma determinada query SQL será "cacheada", isto é, posta em memória real. Então, na primeira vez que a query é executada, o servidor de aplicação efetivamente requisita a consulta ao banco de dados. Entretanto, o resultado de retorno dessa consulta, ou seja o recordset obtido em resposta, é armazenado em memória no servidor de aplicação. Isso significa dizer que, a partir deste momento, se algum usuário requisitar novamente essa mesma query, o banco de dados não será mais incomodado.

O que posso dizer é que o aumento de performance com a técnica é gritante.

As medições de antes e depois da implementação de Cache de Queries mostram situações em que o tempo de carga total de uma página com a query cai de 1 ou 2 segundos para ZERO. É óbvio que algum tempo é gasto no processo para recuperar os dados, ainda que estejam em memória. Mas como a unidade de medida é o milissegundo, o que o servidor de aplicação nos diz é que o tempo gasto foi de zero milissegundos, ou seja, a consulta levou menos de 1 milissegundo para ser executada!

"Uau! Vamos então cachear todas as queries do sistema e resolver todos os nossos problemas!"

Não é bem assim... Há situações que não permitem que uma query seja cacheada. Há de se analisar query por query do sistema, e definir quais delas são elegíveis para o cache. Vamos supor, por exemplo, que o resultado de uma pesquisa dependa de dados que estejam sendo alimentados pelo usuário do sistema. Para ilustrar: Suponha que se esteja pesquisando um aluno pelo seu nome, em uma lista de alunos inscritos. Se é um sistema de inscrição de alunos, e se pusérmos o retorno da pesquisa em cache, alunos inscritos posteriormente ao cacheamento não aparecerão no resultado da pesquisa.

 

Além disso, lembrando de nosso amigo Lavoisier, se ganhamos de um lado, perdemos de outro. Nesse contexto que estamos trabalhando, o ganho é de extraordinária performance. Em detrimento de um uso maior de memória real no servidor de aplicação.

Como sempre, é um ajuste fino. Há que ser estudado com cautela. Mas, como sempre, a relação custo x benefício é positiva.

As linguagens em geral, permitem também, que seja especificado quanto tempo a query ficará em cache, em segundos, minutos, horas ou dias. O resultado de certas queries podem ficar "eternamente" (365 dias) em cache. Por exemplo, no contexto da educação, a query que retorna as séries em determinado ano letivo é uma delas. Como a única chance de ser criada uma série nova é na virada do ano, então a lista das séries pode ficar o ano inteiro em cache.

A conclusão é que, um sistema que não usa cache de queries está aquém do desejado e vai sofrer com certeza, de lentidão, quiçá terá comprometido seu uptime.

Minha opinião pessoal é que todo sistema deve ser desenvolvido com esta técnica desde o princípio, em função dos resultados excepcionais alcançados para o usuário final.

 

No próximo post o assunto será algo igualmente importante: O time-out de queries! Até lá.

Prioridade zero: O banco de dados!

Vou agora começar a mostrar onde geralmente estão os principais gargalos nos sistemas desenvolvidos para web, e algumas técnicas para evitá-los.

A "prioridade número zero" em qualquer sistema que esteja apresentando lentidão e precise ser otimizado é atacar os gargalos no banco de dados.

Pode-se otimizar de tudo em um sistema: a rede, o número de servidores, o poder de processamento dos mesmos, aumentar a quantidade de memória, mas nada disso surtirá o efeito desejado sem uma prévia otimização do banco de dados.

Isso porque no final das contas, toda a cadeia de processos envolvidos dependem dele. Os pedidos dos usuários, em geral, culminam num acesso ao banco de dados.

Portanto, não compensa ficar enxugando a aplicação (por exemplo) para ganhar 10 ou 20 milissegundos na carga de uma página, se não tiver sido feito antes, um ajuste fino no banco de dados.

E, através de modificações triviais no banco de dados, pode-se diminuir segundos do tempo de resposta (em contrapartida aos milissegundos ganhos sob outra abordagem), o que representa um ganho muito mais expressivo na performance geral do sistema, impedindo o enfileiramento de requisições no servidor de aplicação.

 

Note que é assim que se melhora a performance de um sistema. Medindo-se o tempo gasto em cada pequena parte e a otimizando-a, pois cada pequeno processo desses será chamada o número de vezes que requisições forem feitas pela aplicação ao banco de dados. Então é algo que é exponencial.

Os pontos-chave a se observar no contexto do banco de dados são, portanto:

* Otimizar as queries

Tenha o hábito de medir o tempo que leva cada query do seu sistema, do início ao fim do processamento. No Oracle, por exemplo,  isso é feito com o comando "SET TIMING ON". Toda query executada após este comando terá seu tempo de processamento mostrado na tela, em milissegundos. Quanto menor o tempo gasto pela query, melhor. Diria que qualquer valor acima de 1 segundo é indesejável:

    set timing on;
 
    select dsc_serie from serie
    where ind_status = 'A';

    25 linhas selecionadas.
    real: 141 (milissegundos)


* Evitar usar a cláusula IN ou EXISTS nas queries

A cláusula IN em queries SQL são muito lentas. Dê prioridade aos joins.


* Utilizar materialized views para consultas que gerarão relatórios.

Muitos sistemas geram relatórios a partir das próprias tabelas que estão sofrendo inserções e atualizações de dados  pelos usuários do site. Isso cria uma situação de lentidão tanto para quem está requisitando o relatório quanto para quem está entrando ou atualizando dados. A solução é criar uma materialized view com um job associado, que a atualizará de tempos em tempos. Sugiro a pesquisa no Google pelo termo "ETL".

* Utilizar índices nas tabelas.

Os índices criam uma espécie de "mapa" para o banco de dados acessar as informações de forma muito, muito mais rápida. Mas, relembrando a citação de Lavoisier, em contrapartida, tornam a inserção de dados ligeiramente mais lenta, pois algum tempo é necessário para que a indexação seja realizada. No entanto, a relação custo x benefício é vantajosa.

* Restringir o número de linhas no retorno de uma query.

Quando o usuário estiver fazendo uma pesquisa digitando um nome em uma caixa de texto, por exemplo, que gera uma atualização instantânea do conteúdo da caixa (o famoso autocomplete), pode-se especificar na query o número máximo de linhas retornadas. Isso agiliza bastante a resposta. O usuário não perderá informações, pois quanto mais letras digita, mais precisa é a resposta.

* Trazer tabelas específicas inteiras para a memória real

Com a diminuição do preço da memória RAM, é muito comum termos servidores com grande oferta de memória disponível. Algumas empresas já estão utilizando esta técnica para agilizar as consultas a banco de dados - trazer TODO o conteúdo de certas tabelas para a memória real.

Há outras dezenas de técnicas de otimização possíveis no âmbito do banco de dados. Área em que  não sou especialista. Mas certamente, uma equipe de banco de dados saberá responder prontamente a qualquer pedido nesse sentido, fornecendo as melhores estratégias para diminuir o tempo de processamento das queries, que é a necessidade objetiva que tentei passar com este post.

Entretanto... Há uma técnica em especial que é uma daquelas coisas que costumamos dizer que "funciona como mágica", como diz a famosa música do Queen - "It´s a kind of magic!":

 

 

 O Cache de queries.

 

 

Será o tema do nosso próximo post. Imperdível!!!

O gargalo faz da garrafa o que ela é. Mas do congestionamento também!

Um dos mais importantes estratagemas do livro "A arte da guerra", escrito pelo general, filósofo e estrategista chinês Sun Tzu há dois mil e quinhentos anos atrás, enfatiza a importância de conhecer o inimigo:

"Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você conhece a si mesmo, mas não o inimigo, para cada vitória conquistada, você também sofrerá uma derrota."

Em outras palavras, para ser ótimo, é necessário conhecer o inimigo profundamente. Caso contrário, só é possível ser mediano. No contexto da otimização de sistemas, o inimigo em questão é o gargalo.

Mas o que é um gargalo? De que se trata? Por que ele nos aborrece? Ele é sempre ruim? Como evitá-lo? Onde ele aparece?

Bem, um gargalo é um funil. Nada além do que uma resistência à passagem de alguma coisa por um canal. Um filtro. Quantitativo, não qualitativo.

O gargalo de uma garrafa tem a função de restringir a quantidade de líquido que sai dela. E nesse contexto isso é bom. É a função dele, para que o líquido não derrame todo de uma vez. O gargalo é o que faz da garrafa o que ela é! Sem ele, não seria uma garrafa, mas um copo.

Por outro lado, um gargalo também faz de um engarrafamento de veículos em uma avenida ou estrada, o que ele é. E nesse contexto isso não é bom. Deve e pode ser evitado: Pode-se construir  mais vias paralelas de escoamento, definir saídas priorizando ambulâncias, carros de bombeiro, transportes de massa como ônibus, pode-se coibir motoristas que trafegam no acostamento,  induzir motoristas a seguir por uma rota alternativa, pode-se aumentar a velocidade com que os veículos passam pelos pontos de gargalo, pode-se fazer um rodízio de placas naquela via, combinando quem pode trafegar de acordo como dia da semana,  pode-se até mesmo retirar a necessidade de vários motoristas passarem ali diariamente, se forem convencidos a trabalharem de casa. Pode-se aumentar o número de guardas e câmeras na via para monitorar o comportamento do fluxo e obter informações que gerarão ações de correção.

Veja que, utilizando a analogia do engarrafamento no parágrafo acima, citei várias técnicas de otimização de sistemas web, que, quando corretamente aplicadas, podem melhorar sobremaneira o desempenho e a estabilidade de um serviço online.

Antes de optar por uma técnica ou outra (ou por todas), entretanto, é preciso identificar os pontos de gargalo do sistema, que podem estar: na rede (baixo número de rotas para chegar ao servidor de aplicação, lentidão da rede, baixo throughput do canal), no banco de dados (queries mal-escritas, ausência de índices nas tabelas, relatórios que recalculam totais todas as vezes que são chamados), na própria aplicação (páginas muito grandes, imagens muito pesadas, navegação pouco eficiente), e também no layout da estrutura física (poucos servidores de aplicação).

É muito importante, também, saber reconhecer que o sistema não é a aplicação! Já vi diversos projetos que funcionaram na fase de testes não apresentarem o mesmo desempenho ao serem postos em produção. O motivo é que testaram se a aplicação aguentava um certo número de usuários simultâneos, quando deveriam ter testado se o sistema aguentava - o que é completamente diferente.

Um sistema é um conjunto de partes que forma o todo. Portanto, a aplicação, aqui, é apenas parte dele. Há que se considerar desde o computador que o cliente usa, passando pelo canal de acesso,  considerar os servidores, o banco de dados, etc. Esse conjunto de peças é o "sistema", cuja performance deve ser testada antes de ir para produção.

Sem eliminar o gargalo o sistema está fadado a um baixo uptime.

O gargalo gera o enfileiramento no servidor de aplicação. Conforme os usuários requisitam páginas ao sistema web, utilizando seus navegadores, os servidores de aplicação tentam atendê-los da melhor maneira possível (pois é a função deles). Se uma determinada página provoca a execução de uma consulta em um banco de dados e este último demora muito para retornar o resultado, o servidor de aplicação vai colocar o usuário em uma fila e vai tentar atender outras requisições. A medida que os pedidos não estejam conseguindo ser atendidos, a fila cresce exponencialmente. O usuário, percebendo a demora, começa a ficar irritado e tende a pressionar F5 ou o reload em seu navegador, o que piora ainda mais a situação. O resultado é que o inimigo vence a batalha: o sistema sai do ar.

Nos próximos posts conheceremos como podemos enfrentar o gargalo - este inimigo indesejável - e derrotá-lo sempre. Até lá!

Tudo se resume a evitar gargalos...

Após uma década de experiência trabalhando com ajuste fino de sistemas web, posso afirmar, sem sombra de dúvidas, que a frase que intitula este primeiro post no blog sintetiza perfeitamente a idéia do que é a otimização de sistemas que necessitam de alta disponibilidade e desempenho.

Ocorre que, tal qual qualquer serviço disponibilizado a um grande público com canais finitos, há uma tendência a formação de gargalos, que são o maior inimigo do fluxo ininterrupto do processo.

Durante as olimpíadas de Londres em 2012, os organizadores se valeram de uma filosofia conhecida como "go with the flow", na qual eventualmente abriam mão da arrecadação em uma estação de trem, por exemplo, caso o processo de aquisição dos bilhetes pudesse causar um congestionamento de pessoas nas saídas (vale esclarecer que em Londres põe-se o bilhete na saída da estação). Priorizou-se (pontualmente) o fluxo ininterrupto de passageiros em detrimento do faturamento, mas a idéia era evitar situações de risco, que surgiriam se um gargalo fosse instaldo.

Os mesmos princípios podem (e devem) ser aplicados em sistemas web que precisam de um uptime elevado.

É importante salientar que, tal qual a eventual diminuição do faturamento nas estações de trem de Londres durante os jogos de grande público, haverá situações em que será preciso escolher do que abriremos mão no processo, em detrimento de algo de importância semelhante, considerando como principal objetivo o sucesso do processo como um todo.

Como disse o pai da química moderna, Antoine Lavoisier, "na natureza, nada se cria, nada se perde, tudo se transforma". Na informática não seria diferente. Portanto, a questão é mesmo, em última análise, uma arte de ajuste de custo/benefício.

Nos próximos posts mostrarei diversos conceitos e técnicas que podem ser aplicados a qualquer sistema de informática que precise de alta disponibilidade, independente da linguagem de programação utilizada (e essa é a beleza da coisa).

São informações que valem ouro.

Fique ligado!