[IMPORTANTE] – Oracle anuncia fusão de suas Java Virtual Machines

Notícia muito importante retirada do site InfoQ. Espero que dê certo a idéia mesmo, pois são duas excelentes máquinas virtuais. Espero que a Sun Hotspot continue aberta e gratuita, tendo a Oracle a partir de agora três modelos disponíveis de JVM, coisa incrível para a empresa. Leiam a notícia na íntegra abaixo:

No webcast da Oracle que ocorreu na última semana, o principal engenheiro da empresa, Mark Reinhold, disse que uma nova JVM acontecerá em no máximo 2 anos. Esta nova JVM será o resultado da fusão entre a HotSpot da Sun e a JRockit herdada da compra da BEA. Reinhold disse que a empresa continuará mantendo as duas versões da JVM em um curto espaço de tempo, devido a empresas que ainda as utilizam:

Não é tão fácil pegar o melhor de cada uma. Não vamos simplesmente parar de fazer uma delas. Consumidores têm coisas em produção para ambos e tomam vantagem de recursos específicos de cada uma. Não vamos causar um terremoto e fazer os sistemas caírem.

A Oracle já havia expressado a vontade de juntar as duas JVM’s na última sessão do Sun-Oracle roadmap. Ele revelou que a nova JVM finalmente sairá, mas estipulou um prazo entre 18 meses à 2 anos para que isso aconteça. A idéia é unir o melhor dos dois mundo. Reinhold se diz admirado com as funcionalidades da JRockit:

Existem funcões no JRockit que, francamente, sentimos inveja por alguns anos. O controle de missão é muito bom.

Ele diz que a HotSpot também tem muitas vantagens, especialmente vantagens em relação a desempenho:

Acreditamos que o código da HotSpot, especialmente o compilador do servidor, é muito mais sofisticado.

Reinhold também especulou que a junção das JVM’s deve juntar o garbage collector da JRockit e o compilador runtime da HotSpot.

É fascinante aprender mais sobre a JRockit nos últimos dois meses. Ela é realmente um VM incrível.

Ter uma JVM unindo o melhor de duas grandes JVMs é uma boa notícia?

Anúncios

Conceitos Básicos de QoS

Escrevi um artigo a algum tempo no blog do Ensinar (outro blog onde também faço postagens) que tem relações com o assunto de QoS. No caso era sobre a “Importância dos codecs”. Li este artigo no IMasters e achei muito bom, por isso recomendo a leitura desse material. Vide conteúdo abaixo:

Conceitos Básicos de QoS

Neste artigo vamos falar um pouco sobre os conceitos de QoS ou Qualidade de Serviço ( Quality of Services). Os serviços mais tradicionais, como dados, video e voz, possuem suas particularidades na questão de banda, tamanho de pacotes, sensibilidade ao atraso e jitter (variação de atraso).

Mesmo as aplicações de dados possuem requisitos diferentes entre si. O QoS reúne um conjunto de tecnologias e mecanismos que possibilitam a compatibilização de cada aplicação.

Aplicação Tamanho do pacote Atraso entre pacotes Banda miníma Tempo para enviar 1 pacotes (256 kbps)
Dados Variável, até 1500 bytes Variável Variável 47 ms
Vídeoconferência 700 bytes 30 ms 160 kbps 22 ms
Voz sobre IP 60 bytes 20 ms 24 kbps 2 ms

Um bom exemplo, que demonstra claramente como as aplicações se comportam diferentemente entre si, é a definição do tamanho do buffer do roteador. Para suportar de maneira eficiente as transações de comércio eletrônico e a transferência de dados da Web, a rede deve minimizar a perda de pacotes ou mesmo evitá-la por completo. Buffers internos com grande capacidade podem ajudar a atingir estes objetivos. Porém, se os buffers de alta capacidade fornecem um gerenciamento eficiente para este tipo de fluxo de dados, por outro lado eles podem gerar uma alta variação no atraso de propagação dos pacotes, também conhecido como jitter. Os jitter podem ser suportados por aplicações de dados, mas provocam enorme impacto na transmissão de tráfego de aplicações em tempo real, como voz e vídeo. Para isto serve o QoS, melhorar a performance em vários tipos de aplicações.

O serviço padrão oferecido pela rede IP é conhecido como serviço de melhor esforço (Best Effort). Como o próprio nome diz, quando o roteador opera por este este serviço faz sempre o melhor possível para encaminhar os pacotes de acordo com os recursos que ele tem disponíveis naquele instante de tempo, mas sem qualquer garantia de entrega. O serviço Best Effort consiste em oferecer o mesmo tratamento aos pacotes, sem nenhuma distinção entre eles. Este serviço é implementado normalmente pelo mecanismo de gerência de filas FIFO (First In, First Out) pelo qual os pacotes são encaminhados na mesma ordem que chegam ao roteador.

Por este motivo, o serviço Best Effort não atende aos requisitos de qualidade de serviço da maior parte das aplicações.

Qualidade de serviço é uma expressão que, dependendo do contexto, pode significar varias coisas.

Por exemplo, na questão de desempenho de redes, qualidade pode ser descrita como o processo de transmitir dados de uma maneira superior à expectativa. Isto pode ser traduzido numa rede que tenha baixa perda de pacotes, pouco atraso, pequena variação de atraso (jitterr) ou até na capacidade da rede utilizar caminhos mais eficientes.

Em outro sentido, o termo qualidade pode ser considerado como confiabilidade e previsibilidade, quando se refere a níveis constantes de perda de pacotes, atraso, jitter ou qualquer outra propriedade.

A qualidade de serviço também pode ser aplicada ao tratamento diferenciado das aplicações.

Uma aplicação com necessidade de baixo atraso pode ser privilegiada em relação a uma aplicação que não possui sensibilidade a atraso, mas que por sua vez possui necessidade de alta vazão (througput).

Classe de serviço ( CoS – Class of Service)

É uma forma de agrupar diversas aplicações com características comuns, permitindo o tratamento diferenciado em relação a outras classes de serviço (ou grupo de aplicações).

Como vários serviços podem ser oferecidos e utilizados simultaneamente, concorrendo assim pelos recursos da rede, temos que garantir, para cada tipo ou classe de serviço, o nível de serviço adequado ao seu funcionamento.

A identificação de diversos fluxos de dados com a mesma característica facilita a construção de políticas específicas para tratamento daquele tráfego de forma individualizada em cada classe de serviço, indepedentemente de sua origem ou do seu destino.

Qualidade de serviço é, portanto, o tratamento diferenciado do tráfego reunido em classes de serviço, com o objetivo de garantir o nível de serviço adequado a cada aplicação.

Para que uma aplicação tenha desempenho consistente e previsível é necessário observar os requisitos de througput, atraso, jitter e perda de pacotes da mesma.

A qualidade de serviço deverá ser implementada fim-a-fim em todos os pontos da rede, pois se um determinado trecho não suportar e respeitar as definições da política de QoS, passa a ser “o ponto de falha”. A qualidade de serviço da rede será dada pela qualidade de serviço de todos os elementos da rede.

O roteamento pode ser considerado uma forma primitiva de QoS. Ele consiste no encaminhamento de pacotes para o seu destino utilizando a melhor rota possível. A mesma preocupação também tiveram os desenvolvedores do projeto original do IP (RFC 791), quando foi reservado um campo no cabeçalho IP chamado Type of Service (ToS), para oferecer diversos perfis de serviços. Da mesma forma, o protocolo TCP fio implementado com algoritmos de controle de congestionamento que foram aprimorados ao longo do tempo.

Todas estas iniciativas de implementar serviços diferenciados demonstram que a preocupação com QoS é antiga.

8 Boas Práticas Para Melhorar a Escalabilidade

Artigo traduzido, e retirado do InfoQ, voltado a análise de arquitetura, performance e escalabilidade de soluções, com ênfase em banco de dados. .

Wille Faler propõe 8 boas práticas para melhorar desempenho e escalabilidade como diminuir a carga no banco de dados, usar cache, minimizar tráfego na rede, entre outros.

1. Diminua a carga do banco de dados – fique longe do banco de dados o máximo que puder. Isso significa não abrir conexões ou iniciar transações a menos que seja realmente necessário.

2. A diferença que o uso de cache faz – cache diminui significativamente a carga em banco de dados, especialmente em aplicações que somente lêem desse banco. Cache em memória é melhor que cache em disco, que é melhor que um banco de dados relacional ou remoto.

3. Use cache em objetos de baixa granularidade – usar cache em objetos pouco granulares “economiza ciclos de CPU e tempo necessário para consultar n zonas de cache, ao invés de uma somente. Além disso, retornando o grafo do objeto completo economiza tempo ao montar o grafo do objeto.

4. Não armazene estado temporário em memória permanente – evite armazenar dados temporários como dados de sessão para um login em um banco de dados.

O “monstro do estado temporário” é uma besta perigosa. Como regra geral, somente dados de negócio reais, necessários, críticos e prontos para processamento devem ser armazenados de forma permanente (banco de dados, disco); nada mais.

5. Localização, Localização – deixe as coisas perto de onde elas devem ser fornecidas. Em vez de utilizar um balanceador de carga, um servidor web, um servidor de aplicação e um banco de dados, lembre-se que é melhor utilizar um balanceador de carga e um servidor web; e obter parte do conteúdo de uma Rede de Fornecimento de Conteúdo (CDN).

6. Restrinja acesso simultâneo a recursos – se mais de uma requisição acessa o mesmo recurso e executa o mesmo cálculo, é melhor que somente a primeira requisição faça o cálculo até o fim, e as demais requisições somente utilizem o resultado final. Permitir que todas as threads acessem o recurso somente tornará o processo mais lento.

7. Processamento assíncrono e em etapas

Algo que costuma fazer maravilhas para escalabilidade e desempenho é separar um processo de forma que seja assíncrono, dividido em etapas separadas por filas e executadas por um número limitado de threads em cada etapa.

8. Diminua a comunicação na rede – tente fazer com que sua aplicação se comunique o mínimo possível através da rede, pois é um processo muito mais lento do que comunicação em memória.

Steve M. Ciske, comentando sobre o post do Faler, é cauteloso em relação a reduzir a carga do banco de dados:

Eu tomaria cuidado ao diminuir a carga do banco de dados. Já vi pessoas no outro extremo que colocam tudo na camada de aplicação.

Pawel Stradomski considera cache remoto em memória mais rápido do que cache local em disco e Faler concorda com ele:

O uso de cache em um host remoto (via rede) pode ser mais rápido que o uso de cache em um disco local. A leitura dados sequenciais em um disco é por volta de três vezes mais lenta que a leitura na memória de hosts remotos; isso desconsiderando o tempo de busca.

Fonte relacionada: Simon Brown escreveu um artigo sobre princípios de escalabilidade.