Posts de September, 2008

[Bruno Mentges de Carvalho] Rails Summit, eu vou

Friday, September 26th, 2008

Dias 15 e 16 de outubro estarei em São Paulo para prestigiar o evento Rails Summit. Vou com o Guilherme Chapiewski e espero encontrar todo mundo lá. O evento vai contar com palestras de desenvolvedores importantes como David Chelimsky, Chad Fowler, Jay Fields, Carlos Vilella, Os koreanos da Phusion (<3 passenger), Charles Nutter, Danilo Sato, Fabio Kung e Obie Fernandez.

Nos vemos lá.

[Bruno Mentges de Carvalho] Rails Summit, eu vou

Friday, September 26th, 2008

Dias 15 e 16 de outubro estarei em São Paulo para prestigiar o evento Rails Summit. Vou com o Guilherme Chapiewski e espero encontrar todo mundo lá. O evento vai contar com palestras de desenvolvedores importantes como David Chelimsky, Chad Fowler, Jay Fields, Carlos Vilella, Os koreanos da Phusion (<3 passenger), Charles Nutter, Danilo Sato, Fabio Kung e Obie Fernandez.

Nos vemos lá.

[Christiane Melcher] Globo Amazônia e Amazonia.vc no ar!

Friday, September 26th, 2008

Estava aqui pensando em como escrever o primeiro post deste blog, sobre um projeto em que fiquei tão feliz de ter feito. Já tive outros blogs, mas nunca consegui atualizar com a freqüência que gostaria. Mas, agora chegou a hora de me dedicar à este aqui. Há muito tempo que quero retomar o hábito de blogar e nada como começar com um projeto que acabou de sair do forno ;-)

Globo Amazônia surgiu de uma parceria entre o Fantástico e a Globo.com, mais precisamente na linha de Scrum de Aplicativos de Jornalismo (G1), vulgo equipe A3 (para quem não sabe, Scrum é uma metodologia de trabalho ágil adotada em toda Globo.com. A empresa foi fatiada em pequenas equipes. Depois explico melhor em outro post).

Essa equipe A3 é formada por 10 pessoas (1 Product Owner, 1 Scrum Master, 1 designer, eu – como arquiteta da informação, 1 HTMLer, 1 estagiário e 4 desenvolvedores). O desafio do projeto era tratar de um tema tão sério como as queimadas e o desmatamento na Amazônia sem tornar o projeto chato, cansativo e pouco interessante. Era preciso mostrar ao mundo, de forma fácil, o que está acontecendo na Amazônia e criar um espaço para as pessoas se manifestarem sobre o assunto, além de chamar a atenção do governo, através de uma mobilização nacional.

Causa mais do que nobre e justificada, o desafio estava lançado. Começamos então fazendo um sprint de conceituação e pré-projeto (depois explico isso também, é um termo usado em Scrum para períodos de desenvolvimento/entregas de projeto). Neste sprint surgiram várias idéias megalomaníacas. Mas, ainda faltava adequar isso aos prazos/custos e compromissos assumidos. Foi aí que surgiu a idéia de fazer um aplicativo do Orkut, o Amazonia.vc. Ao invés de reinventarmos a roda, por que não aproveitarmos a existência de uma rede social já aceita pelos brasileiros e levar nossa causa para lá? Dito e feito :-)

Amazonia.vc - mapa A cada sprint, começamos a trabalhar em funcionalidades novas. A idéia era fazer um mashup com o Google Maps utilizando os dados públicos do INPE (Instituto Nacional de Pesquisas Espaciais) e mostrar as queimadas em tempo real e o desmatamento na Amazônia. Mas, faltava algo. Os usuários tinham que participar de alguma maneira. Afinal, era uma causa nobre, que precisava de mobilização nacional utilizando uma rede social onde as pessoas interagem.

Foi aí que surgiu a idéia do protesto. As pessoas deveriam conseguir protestar em cada ponto de queimada/desmatamento e mostrar ao mundo que o que está acontecendo é algo reprovado por todos, além de ajudar a chamar a atenção para as áreas em que o desmatamento e as queimadas só se multiplicam. Assim foi criado o ranking de protestos.

Amazonia.vc - ranking de protestos Como toda idéia, a evolução foi trazendo algumas informações a mais e outras funcionalidades. Foi levantado o total de área desmatada até hoje (colocado de forma destacada na home do aplicativo) e, para facilitar a visualização das áreas já protestadas, foi disponibilizado um ícone para indicar os locais onde o usuário já protestou. As notícias do portal também foram integradas ao aplicativo e por aí vai… Idéias a mais é o que não faltam! Ainda tem muito por vir :-)

Depois de adiantar o aplicativo, começamos a fazer o portal Globo Amazônia. Foi um grande desafio trazer o mapa interativo e o ranking de usuários para um portal fora do Orkut. Algo totalmente novo na Globo.com. Assim, quem não tem Orkut, e também quem não pretende tê-lo, pode acompanhar através do mapa interativo.

Globo Amazônia

O lançamento do projeto aconteceu no Fantástico do dia 7 de setembro e foi um sucesso. Nas primeiras 17 horas chegamos a 1 milhão de protestos. Algo completamente fora do previsto, o que nos deixou ainda mais felizes. Afinal, se cada um fizer um pouquinho, a gente chega lá! No Orkut também ficamos em terceiro lugar na página que lista todos os aplicativos disponíveis, o que é algo nunca alcançado antes por um aplicativo que não visa apenas o entretenimento. Depois vieram matérias no Jornal Nacional, Jornal Hoje, Fantástico novamente , Jô Soares e Profissão Repórter. É o Globo Amazônia invadindo a programação da TV!

Uma outra coisa importante nisso tudo foi a entrevista que o ministro Carlos Minc deu ao Globo Amazônia, quando disse que estará sempre de olho no portal e assumiu o compromisso de responder aos internautas que estão protestando no aplicativo. A ex-ministra do Meio Ambiente Marina Silva também mencionou a importância dos protestos dos internautas em seu último discurso no Senado .

Hoje, quase 20 dias depois do lançamento, já foram feitos quase 17 milhões de protestos e 285 mil instalações só no Orkut, o que indica que, para um aplicativo de cunho social, o resultado alcançado já superou todas as metas e expectativas. E o ano de 2009 ainda promete mais!

Para conhecer o projeto, acesse o portal Globo Amazônia e instale o aplicativo do Orkut Amazonia.vc

[Christiane Melcher] Globo Amazônia e Amazonia.vc no ar!

Friday, September 26th, 2008

Estava aqui pensando em como escrever o primeiro post deste blog, sobre um projeto em que fiquei tão feliz de ter feito. Já tive outros blogs, mas nunca consegui atualizar com a freqüência que gostaria. Mas, agora chegou a hora de me dedicar à este aqui. Há muito tempo que quero retomar o hábito de blogar e nada como começar com um projeto que acabou de sair do forno ;-)

Globo Amazônia surgiu de uma parceria entre o Fantástico e a Globo.com, mais precisamente na linha de Scrum de Aplicativos de Jornalismo (G1), vulgo equipe A3 (para quem não sabe, Scrum é uma metodologia de trabalho ágil adotada em toda Globo.com. A empresa foi fatiada em pequenas equipes. Depois explico melhor em outro post).

Essa equipe A3 é formada por 10 pessoas (1 Product Owner, 1 Scrum Master, 1 designer, eu - como arquiteta da informação, 1 HTMLer, 1 estagiário e 4 desenvolvedores). O desafio do projeto era tratar de um tema tão sério como as queimadas e o desmatamento na Amazônia sem tornar o projeto chato, cansativo e pouco interessante. Era preciso mostrar ao mundo, de forma fácil, o que está acontecendo na Amazônia e criar um espaço para as pessoas se manifestarem sobre o assunto, além de chamar a atenção do governo, através de uma mobilização nacional.

Causa mais do que nobre e justificada, o desafio estava lançado. Começamos então fazendo um sprint de conceituação e pré-projeto (depois explico isso também, é um termo usado em Scrum para períodos de desenvolvimento/entregas de projeto). Neste sprint surgiram várias idéias megalomaníacas. Mas, ainda faltava adequar isso aos prazos/custos e compromissos assumidos. Foi aí que surgiu a idéia de fazer um aplicativo do Orkut, o Amazonia.vc. Ao invés de reinventarmos a roda, por que não aproveitarmos a existência de uma rede social já aceita pelos brasileiros e levar nossa causa para lá? Dito e feito :-)

Amazonia.vc - mapa A cada sprint, começamos a trabalhar em funcionalidades novas. A idéia era fazer um mashup com o Google Maps utilizando os dados públicos do INPE (Instituto Nacional de Pesquisas Espaciais) e mostrar as queimadas em tempo real e o desmatamento na Amazônia. Mas, faltava algo. Os usuários tinham que participar de alguma maneira. Afinal, era uma causa nobre, que precisava de mobilização nacional utilizando uma rede social onde as pessoas interagem.

Foi aí que surgiu a idéia do protesto. As pessoas deveriam conseguir protestar em cada ponto de queimada/desmatamento e mostrar ao mundo que o que está acontecendo é algo reprovado por todos, além de ajudar a chamar a atenção para as áreas em que o desmatamento e as queimadas só se multiplicam. Assim foi criado o ranking de protestos.

Amazonia.vc - ranking de protestos Como toda idéia, a evolução foi trazendo algumas informações a mais e outras funcionalidades. Foi levantado o total de área desmatada até hoje (colocado de forma destacada na home do aplicativo) e, para facilitar a visualização das áreas já protestadas, foi disponibilizado um ícone para indicar os locais onde o usuário já protestou. As notícias do portal também foram integradas ao aplicativo e por aí vai… Idéias a mais é o que não faltam! Ainda tem muito por vir :-)

Depois de adiantar o aplicativo, começamos a fazer o portal Globo Amazônia. Foi um grande desafio trazer o mapa interativo e o ranking de usuários para um portal fora do Orkut. Algo totalmente novo na Globo.com. Assim, quem não tem Orkut, e também quem não pretende tê-lo, pode acompanhar através do mapa interativo.

Globo Amazônia

O lançamento do projeto aconteceu no Fantástico do dia 7 de setembro e foi um sucesso. Nas primeiras 17 horas chegamos a 1 milhão de protestos. Algo completamente fora do previsto, o que nos deixou ainda mais felizes. Afinal, se cada um fizer um pouquinho, a gente chega lá! No Orkut também ficamos em terceiro lugar na página que lista todos os aplicativos disponíveis, o que é algo nunca alcançado antes por um aplicativo que não visa apenas o entretenimento. Depois vieram matérias no Jornal Nacional, Jornal Hoje, Fantástico novamente , Jô Soares e Profissão Repórter. É o Globo Amazônia invadindo a programação da TV!

Uma outra coisa importante nisso tudo foi a entrevista que o ministro Carlos Minc deu ao Globo Amazônia, quando disse que estará sempre de olho no portal e assumiu o compromisso de responder aos internautas que estão protestando no aplicativo. A ex-ministra do Meio Ambiente Marina Silva também mencionou a importância dos protestos dos internautas em seu último discurso no Senado .

Hoje, quase 20 dias depois do lançamento, já foram feitos quase 17 milhões de protestos e 285 mil instalações só no Orkut, o que indica que, para um aplicativo de cunho social, o resultado alcançado já superou todas as metas e expectativas. E o ano de 2009 ainda promete mais!

Para conhecer o projeto, acesse o portal Globo Amazônia e instale o aplicativo do Orkut Amazonia.vc

[Rafael Silva Pereira] Globo Vídeos para iPhone

Thursday, September 25th, 2008

A Globo.com lançou hoje, oficialmente, seu portal de vídeos para iPhone: http://m.video.globo.com. Agora é possível ver os vídeos da Globo.com de qualquer celular que suporte vídeos H.264!!!

Globo Videos para iPhone

Globo Vídeos para iPhone

Foi desenvolvida do zero uma nova versão do site, otimizada para iPhone e iPod Touch, com os já conhecidos efeitos de transição. Todo este trabalho foi realizado em pouco mais de um mês, desde a criação até o desenvolvimento, passando pelo setup da infra-estrututra de distribuição, estudos e pesquisas para otimizar a qualidade dos vídeos, implementação, etc, e isto só foi possível devido à utilização de metodologias ágeis, que definitivamente mudaram a forma como trabalhamos aqui, o que sem dúvida nenhuma permite uma resposta mais eficiente às demandas do mercado de internet.

Além de ver os vídeos no site, é possível reproduzir todos os vídeos do portal, mesmo aqueles que estão embedded em matérias, como os que encontramos no G1 e Globoesporte.com

Com relação à qualidade dos vídeos, posso dizer que conseguimos uma otimização bem legal, onde temos um vídeo de ótima qualidade (33dB) para o bitrate que escolhemos, que é limitado ao throughput máximo das redes 3G.

Video da Globo.com no iPhone

Vídeo da Globo.com no iPhone / iPod Touch

Mais uma vez conseguimos entregar um produto inovador, de qualidade, o que prova que estamos no caminho certo. Parabéns galera!!!

[Rafael Silva Pereira] Globo Vídeos para iPhone

Thursday, September 25th, 2008

A Globo.com lançou hoje, oficialmente, seu portal de vídeos para iPhone: http://m.video.globo.com. Agora é possível ver os vídeos da Globo.com de qualquer celular que suporte vídeos H.264!!!

Globo Videos para iPhone

Globo Vídeos para iPhone

Foi desenvolvida do zero uma nova versão do site, otimizada para iPhone e iPod Touch, com os já conhecidos efeitos de transição. Todo este trabalho foi realizado em pouco mais de um mês, desde a criação até o desenvolvimento, passando pelo setup da infra-estrututra de distribuição, estudos e pesquisas para otimizar a qualidade dos vídeos, implementação, etc, e isto só foi possível devido à utilização de metodologias ágeis, que definitivamente mudaram a forma como trabalhamos aqui, o que sem dúvida nenhuma permite uma resposta mais eficiente às demandas do mercado de internet.

Além de ver os vídeos no site, é possível reproduzir todos os vídeos do portal, mesmo aqueles que estão embedded em matérias, como os que encontramos no G1 e Globoesporte.com

Com relação à qualidade dos vídeos, posso dizer que conseguimos uma otimização bem legal, onde temos um vídeo de ótima qualidade (33dB) para o bitrate que escolhemos, que é limitado ao throughput máximo das redes 3G.

Video da Globo.com no iPhone

Vídeo da Globo.com no iPhone / iPod Touch

Mais uma vez conseguimos entregar um produto inovador, de qualidade, o que prova que estamos no caminho certo. Parabéns galera!!!

[Guilherme Cirne] Globo Vídeos no seu iPhone

Thursday, September 25th, 2008

Já está no ar uma versão do Globo Vídeos otimizada para iPhone em http://m.video.globo.com. Com direito a efeitos que os usuários deste aparelho já estão acostumados, como transições ao navegar de uma página para outra, e de girar o aparelho.

Graças aos métodos ágeis que usamos aqui na Globo.com, o site foi totalmente desenvolvido em 2 sprints de 2 semanas. Quando digo totalmente, foi desde a infraestrutura necessária para produzir vídeos até o site propriamente dito.

Me arrisco a dizer que é um dos melhores sites para iPhone existentes. Certamente merece todo o nosso respeito tecnológico!

Além disso, agora também é possível assistir no iPhone os vídeos disponíveis nas versões clássicas dos sites da Globo.com, como G1 e Globoesporte. Essa funcionalidade surgiu como um projeto pessoal da nossa equipe sendo lançado agora também.

O Guilherme Chapiewski fala mais em seu blog tanto sobre o Globo Vídeos Mobile quanto sobre os vídeos para iPhone nas versões clássicas dos sites Globo.com, inclusive com screenshots.

[Tiago Motta] Cópia exclusiva de coleção

Thursday, September 18th, 2008

Por serem de díficil identificação, problemas de concorrência acabam indo pra produção sem sequer serem notado em ambiente de testes e desenvolvimento. Erros acabam ocorrendo de maneira intermitente, causando dores de cabeça e acessos de insanidade nos desenvolvedores. Martin Fowler em seu livro Patterns of Enterprise Application Architecture identifica algumas soluções para evitar problemas de concorrência relativos a integridade de dados. Contudo há um outro problema que não está catalogado neste livro: A concorrência de informações na memória.

Ao guardar objetos em uma coleção que é compartilhada por outras threads, é necessário tomar providências para que não sejam lançadas exceções inesperadas. A medida básica é garantir que os pontos de acesso às coleções compartilhadas devem obter exclusividade sobre seu uso com a diretiva synchronized. Veja abaixo um exemplo de classe que torna o uso de uma lista à prova de erros de concorrência:

public class ListaSegura {    private List lista = new ArrayList();    public void adiciona(Object objeto) {        synchronized (lista) {            lista.add(objeto);        }    }    public void remove(Object objeto) {        synchronized (lista) {            lista.remove(objeto);        }    }    public void listar() {        synchronized (lista) {            for (Object o : lista) {                System.out.println(o);            }        }    }}

É uma solução simples e que resolve em parte o problema. Contudo na maioria das vezes não podemos obter a exclusividade para iterar sobre uma coleção. No caso mostrado acima isso é possível pois estamos apenas imprimindo o objeto. Mas existem alguns casos em que obter essa exclusividade para a iteração nos traria alguns problemas. Esses casos estão descritos abaixo:

1- Alteração da coleção: No caso de você iterar pela coleção para remover ou adicionar algum objeto a ela. A exclusão ou adição ocorreria no meio da iteração e com isso seria lançada uma exceção de concorrência.Um exemplo simples disso são classes que gerenciam cache e precisam periodicamente remover objetos expirados.

2- Iteração prolongada: Quando a coleção possui objetos demais ou o processo executado durante a iteração é lento, tornando o tempo de exclusividade total muito longo. Isso faria com que o restante do sistema que precisasse utilizar essa coleção ficasse muito tempo aguardando pela exclusividade terminar. Um exemplo comum é a execução de métodos que acessem banco de dados dentro da iteração de um objeto exclusivo.

Para resolver esses dois casos identifiquei o padrão de desenvolvimento Cópia Exclusiva de Coleção. A idéia é obter a exclusividade da lista somente para fazer uma cópia dos itens em outra coleção e então poder iterar sobre esta cópia sem muitas preocupações. Abaixo mostro um exemplo de uma classe Armario que possui muitas Coisas. Se alguma coisa for lixo, ela deve ser removida na execução do método removeLixo.

public class Armario {    private List coisas = new LinkedList();    public void removeLixo() {        List copia = lista();        for (Coisa coisa : copia) {            if (coisa.isLixo())                remove(coisa);        }    }        public List lista() {        List copia = null;        synchronized (coisas) {            copia = new ArrayList(coisas.size());            copia.addAll(coisas);        }        return copia;    }    public void adiciona(Coisa coisa) {        synchronized (coisas) {            coisas.add(coisa);        }    }    public void remove(Coisa coisa) {        synchronized (coisas) {            coisas.remove(coisa);        }    }}

Com isso o tempo de exclusividade fica restrito ao tempo da cópia para a outra coleção, que ocorre no método lista. Dessa forma temos uma folga no tempo de iteração total e a possibilidade de rearranjar a coleção, adicionando ou removendo itens a ela. É importante ressaltar que o melhor jeito de evitar o calafrio de receber um java.util.ConcurrentModificationException é evitar a utilização de objetos compartilhados entre threads. Quando isso não é possível, o jeito é utilizar um padrão como Cópia Exclusiva de Coleção.

[Rafael Silva Pereira] Otimizando um Servidor Web para Download Progressivo

Thursday, September 18th, 2008

No dia 27 do mês passado estive no Congresso SET, da Sociedade Brasileira de Engenharia de Televisão e Telecomunicações, onde apresentei junto com o Marcello Azambuja um artigo sobre Arquiteturas de Distribuição de Vídeos na Internet. Porém, devido ao tempo bastante limitado da apresentação, não pude entrar em detalhes mais específicos de como otimizar as arquiteturas para obter um melhor desempenho. Por isso, resolvi colocar um pouco do que está no artigo aqui no blog, já que nem todo mundo que tem interesse neste assunto estava na apresentação. (O slides podem ser vistos aqui)

Assim, resolvi começar falando especificamente sobre o Download Progressivo, ou seja, como podemos otimizar um Web Server para que ele seja capaz de servir a maior quantidade de usuários possível. No caso de distribuição de vídeos via Progressive Download temos algumas características básicas que devem ser consideradas para otimização:

  • As conexões com o WebServer são persistentes, ou seja, o usuário fica conectado ao servidor por uma quantidade razoável de tempo, até que o conteúdo seja completamente copiado;
  • Dependendo da quantidade de vídeos diferentes podemos ter diversos conteúdos diferentes sendo acessados simultaneamente;
  • Os arquivos de mídia não estão necessariamente nos discos do servidor. Eles podem estar em um repositório central sendo acessados pelo servidor Web através de NFS/CIFS;
  • A quantidade de acessos ao serviço pode aumentar rapidamente, variando de acordo com o conteúdo disponibilizado;

Com estas características já podemos identificar alguns gargalos principais:

  • Tráfego de rede: muitos usuários conectados realizando download irão rapidamente ocupar a banda disponível. Além disso, existe a ocupação de banda pela cópia dos arquivos do repositório central para o servidor;
  • IO (Repositório Central e Disco Local): muitos usuários realizando download significa muito IO de leitura, que é maior a medida que temos mais usuários acessando arquivos diferentes;
  • Memória: quanto mais usuários, mais memória o Apache irá precisar para atendê-los, e quanto mais arquivos, mais memória o kernel irá utilizar para cache;
  • CPU: quanto mais usuários mais processamento para organizar e servir as requisições;

Na verdade, se queremos obter o máximo de uma arquitetura não podemos nos limitar a olhar apenas um componente. O primeiro ponto, e mais simples, consiste em alterar as configurações do Apache, escolher a versão correta (2.X), e compilar uma versão do Web Server que tenha apenas aquilo que é relevante para a distribuição de arquivos, ou seja, devemos evitar incluir na configuração de compilação módulos que não serão utilizados, como mod ssl, por exemplo.

Uma vez compilado cabe a nós decidir qual arquitetura interna de funcionamento possui uma performance maior: se é a multi-process (Apache Prefork) ou a multi-process/multi-thread (Apache Worker).

Basicamente, no prefork, para cada conexão será criado um processo específico para atendê-la, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados para atender as conexões, sendo que a medida que os clientes se conectam, eles são atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de performance:

  • Memória: cada processo criado ocupa uma porção da memória, de modo que a memória disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
  • Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas conexões;

A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma área de memória do processo pai, e reduzimos o overhead na criação de processos. Na verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só realizamos um fork quando este limite é atingido.

A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra. No caso específico de servidores para utilização em distribuição de vídeos em Progressive Download, a escolha do MPM Worker é recomendada, com o objetivo de reduzir a ocupação de memória pelo servidor Web, deixando-a livre para que o kernel possa utilizá-la para cache de conteúdo, reduzindo o IO no disco e conseqüentemente o tempo de resposta da requisição. Uma configuração interessante seria neste caso seria forçar a criação de todos os processos filho (children) e suas threads no momento que o servidor Web for iniciado, reduzindo assim o overhead de controle de threads.

Além de configurar o MPM, o Apache permite diversas outras configurações capazes de aumentar o desempenho do mesmo, como a possibilidade de desabilitar Hostname Lookups e DNS resolving, e outras que podem ser encontradas na documentação do Apache.

Entretanto, quando falamos de arquiteturas de distribuição de vídeo que recebem grandes volumes de acesso, devemos nos preocupar um pouco mais em como otimizar o processo de distribuição. Uma das maneiras mais eficientes de aumentar a capacidade de uma infra-estrutura de Download Progressivo consiste em realizar um processo de cache intensivo. Ter uma estratégia de cache de conteúdo é fundamental quando falamos de alta performance com um grande volume de acessos. Quando temos um volume muito grande, temos também diversos requests ao mesmo conteúdo. Processar todo o request para cada cliente consistiria em repetir as mesmas operações diversas vezes, sem aproveitar para um request os dados processados por outro. Assim, fica claro que podemos otimizar este processamento, simplesmente aproveitando aquilo que serve para mais de uma requisição.

Em situações onde temos uma arquitetura onde o Apache funciona como uma espécie de “proxy” entre o usuário e um repositório central de vídeos, essa necessidade é ainda mais latente, uma vez que não faz sentido obter um mesmo arquivo diversas vezes neste repositório para servir para os clientes a cada request semelhante. Uma vez copiado do storage para o Apache, para servir uma requisição, o arquivo pode ser mantido no servidor Web para as requisições posteriores realizadas ao mesmo vídeo. Com essa abordagem, reduzimos a carga no storage e o tráfego de rede e de operações de cópia.

Para realizar o cache de conteúdo existem diversas alternativas, como o Squid e o mod_cache. O mod_cache, por estar integrado ao Apache e por ser bastante conhecido e utilizado, além de apresentar uma ótima performance, é uma excelente opção para cache em arquiteturas de distribuição em Download Progressivo.

O mod_cache permite duas abordagens principais de cache: disco ou memória. O mod_disk_cache é o módulo responsável pelo cache em disco, e funciona da seguinte forma: ao receber um request, o mod_disk_cache verifica se o conteúdo solicitado já está no cache em disco. Se estiver, o módulo valida se o conteúdo não está expirado e serve o mesmo a partir do cache, sem que a requisição seja passada aos demais módulos do Apache. Caso, não esteja cacheado, o request passa pelo path normal de atendimento ao request, sendo que, ao finalizar o processamento, o mod_cache escreve a resposta no cache antes de servir a mesma. Assim, ele cria dois arquivos em disco: o .data, com o conteúdo do request, e o .header com os headers da resposta. O nome dos arquivos criados é criado a partir de um hash, para evitar que o conteúdo seja sobre-escrito.

O mod_mem_cache, é o módulo responsável pelo cache em memória, e funciona de forma semelhante ao mod_disk_cache, porém armazenando o conteúdo em memória.

A escolha de um dos módulos para utilização em um servidor de Download Progressivo também depende da configuração do hardware. Entretanto, em servidores que rodam em Linux, o uso do mod_disk_cache é recomendada, uma vez que o gerenciamento do cache em memória feito pelo kernel é bastante eficiente.

Com um web server bem otimizado e configurado, e com uma estratégia de cache eficiente, temos uma arquitetura de distribuição muito mais robusta e capaz de atender um volume até 70% maior que o volume que atenderíamos utilizando apenas um servidor com as configurações “default”, o que reduz de forma significativa os custos de investimento para expansão da capacidade, tornando esta uma opção bastante interessante para distribuição de vídeos na internet.

[Rafael Silva Pereira] Otimizando um Servidor Web para Download Progressivo

Thursday, September 18th, 2008

No dia 27 do mês passado estive no Congresso SET, da Sociedade Brasileira de Engenharia de Televisão e Telecomunicações, onde apresentei junto com o Marcello Azambuja um artigo sobre Arquiteturas de Distribuição de Vídeos na Internet. Porém, devido ao tempo bastante limitado da apresentação, não pude entrar em detalhes mais específicos de como otimizar as arquiteturas para obter um melhor desempenho. Por isso, resolvi colocar um pouco do que está no artigo aqui no blog, já que nem todo mundo que tem interesse neste assunto estava na apresentação. (O slides podem ser vistos aqui)

Assim, resolvi começar falando especificamente sobre o Download Progressivo, ou seja, como podemos otimizar um Web Server para que ele seja capaz de servir a maior quantidade de usuários possível. No caso de distribuição de vídeos via Progressive Download temos algumas características básicas que devem ser consideradas para otimização:

  • As conexões com o WebServer são persistentes, ou seja, o usuário fica conectado ao servidor por uma quantidade razoável de tempo, até que o conteúdo seja completamente copiado;
  • Dependendo da quantidade de vídeos diferentes podemos ter diversos conteúdos diferentes sendo acessados simultaneamente;
  • Os arquivos de mídia não estão necessariamente nos discos do servidor. Eles podem estar em um repositório central sendo acessados pelo servidor Web através de NFS/CIFS;
  • A quantidade de acessos ao serviço pode aumentar rapidamente, variando de acordo com o conteúdo disponibilizado;

Com estas características já podemos identificar alguns gargalos principais:

  • Tráfego de rede: muitos usuários conectados realizando download irão rapidamente ocupar a banda disponível. Além disso, existe a ocupação de banda pela cópia dos arquivos do repositório central para o servidor;
  • IO (Repositório Central e Disco Local): muitos usuários realizando download significa muito IO de leitura, que é maior a medida que temos mais usuários acessando arquivos diferentes;
  • Memória: quanto mais usuários, mais memória o Apache irá precisar para atendê-los, e quanto mais arquivos, mais memória o kernel irá utilizar para cache;
  • CPU: quanto mais usuários mais processamento para organizar e servir as requisições;

Na verdade, se queremos obter o máximo de uma arquitetura não podemos nos limitar a olhar apenas um componente. O primeiro ponto, e mais simples, consiste em alterar as configurações do Apache, escolher a versão correta (2.X), e compilar uma versão do Web Server que tenha apenas aquilo que é relevante para a distribuição de arquivos, ou seja, devemos evitar incluir na configuração de compilação módulos que não serão utilizados, como mod ssl, por exemplo.

Uma vez compilado cabe a nós decidir qual arquitetura interna de funcionamento possui uma performance maior: se é a multi-process (Apache Prefork) ou a multi-process/multi-thread (Apache Worker).

Basicamente, no prefork, para cada conexão será criado um processo específico para atendê-la, de modo que a quantidade de processos httpd será sempre maior ou igual a quantidade de clientes. Nesta arquitetura, temos uma quantidade inicial que processos que são pré-criados para atender as conexões, sendo que a medida que os clientes se conectam, eles são atendidos por estes processos. No prefork, temos basicamente dois problemas em termos de performance:

  • Memória: cada processo criado ocupa uma porção da memória, de modo que a memória disponível para cache do kernel é cada vez menor, ao ponto que toda ela é preenchida pelos processos httpd, momento onde o servidor começa a fazer swap em disco;
  • Load: a criação de novos processos (fork) gera um overhead no sistema, de modo que quanto maior a taxa de conexão, maior será o overhead no fork para atender as novas conexões;

A outra opção de MPM, o worker, trabalha com o conceito multi-thread, onde as requisições são atendidas por threads e não por processos. Assim, teríamos apenas um ou poucos processos com múltiplas threads em cada um deles, atendendo cada uma das conexões. Com o worker, minimizamos a utlização de memória, já que as threads compartilham a mesma área de memória do processo pai, e reduzimos o overhead na criação de processos. Na verdade, no caso do worker, definimos a quantidade de threads por processo de modo que só realizamos um fork quando este limite é atingido.

A escolha entre prefork ou worker deve ser realizada caso a caso, ou seja, dependendo da situação de uso e da configuração de hardware uma escolha poderá ser melhor que a outra. No caso específico de servidores para utilização em distribuição de vídeos em Progressive Download, a escolha do MPM Worker é recomendada, com o objetivo de reduzir a ocupação de memória pelo servidor Web, deixando-a livre para que o kernel possa utilizá-la para cache de conteúdo, reduzindo o IO no disco e conseqüentemente o tempo de resposta da requisição. Uma configuração interessante seria neste caso seria forçar a criação de todos os processos filho (children) e suas threads no momento que o servidor Web for iniciado, reduzindo assim o overhead de controle de threads.

Além de configurar o MPM, o Apache permite diversas outras configurações capazes de aumentar o desempenho do mesmo, como a possibilidade de desabilitar Hostname Lookups e DNS resolving, e outras que podem ser encontradas na documentação do Apache.

Entretanto, quando falamos de arquiteturas de distribuição de vídeo que recebem grandes volumes de acesso, devemos nos preocupar um pouco mais em como otimizar o processo de distribuição. Uma das maneiras mais eficientes de aumentar a capacidade de uma infra-estrutura de Download Progressivo consiste em realizar um processo de cache intensivo. Ter uma estratégia de cache de conteúdo é fundamental quando falamos de alta performance com um grande volume de acessos. Quando temos um volume muito grande, temos também diversos requests ao mesmo conteúdo. Processar todo o request para cada cliente consistiria em repetir as mesmas operações diversas vezes, sem aproveitar para um request os dados processados por outro. Assim, fica claro que podemos otimizar este processamento, simplesmente aproveitando aquilo que serve para mais de uma requisição.

Em situações onde temos uma arquitetura onde o Apache funciona como uma espécie de “proxy” entre o usuário e um repositório central de vídeos, essa necessidade é ainda mais latente, uma vez que não faz sentido obter um mesmo arquivo diversas vezes neste repositório para servir para os clientes a cada request semelhante. Uma vez copiado do storage para o Apache, para servir uma requisição, o arquivo pode ser mantido no servidor Web para as requisições posteriores realizadas ao mesmo vídeo. Com essa abordagem, reduzimos a carga no storage e o tráfego de rede e de operações de cópia.

Para realizar o cache de conteúdo existem diversas alternativas, como o Squid e o mod_cache. O mod_cache, por estar integrado ao Apache e por ser bastante conhecido e utilizado, além de apresentar uma ótima performance, é uma excelente opção para cache em arquiteturas de distribuição em Download Progressivo.

O mod_cache permite duas abordagens principais de cache: disco ou memória. O mod_disk_cache é o módulo responsável pelo cache em disco, e funciona da seguinte forma: ao receber um request, o mod_disk_cache verifica se o conteúdo solicitado já está no cache em disco. Se estiver, o módulo valida se o conteúdo não está expirado e serve o mesmo a partir do cache, sem que a requisição seja passada aos demais módulos do Apache. Caso, não esteja cacheado, o request passa pelo path normal de atendimento ao request, sendo que, ao finalizar o processamento, o mod_cache escreve a resposta no cache antes de servir a mesma. Assim, ele cria dois arquivos em disco: o .data, com o conteúdo do request, e o .header com os headers da resposta. O nome dos arquivos criados é criado a partir de um hash, para evitar que o conteúdo seja sobre-escrito.

O mod_mem_cache, é o módulo responsável pelo cache em memória, e funciona de forma semelhante ao mod_disk_cache, porém armazenando o conteúdo em memória.

A escolha de um dos módulos para utilização em um servidor de Download Progressivo também depende da configuração do hardware. Entretanto, em servidores que rodam em Linux, o uso do mod_disk_cache é recomendada, uma vez que o gerenciamento do cache em memória feito pelo kernel é bastante eficiente.

Com um web server bem otimizado e configurado, e com uma estratégia de cache eficiente, temos uma arquitetura de distribuição muito mais robusta e capaz de atender um volume até 70% maior que o volume que atenderíamos utilizando apenas um servidor com as configurações “default”, o que reduz de forma significativa os custos de investimento para expansão da capacidade, tornando esta uma opção bastante interessante para distribuição de vídeos na internet.