Só 11% dos brasileiros confiam nos políticos, aponta pesquisa

Uma pesquisa divulgada nesta quinta-feira pela Associação dos Magistrados Brasileiros (AMB) mostra que apenas 11% dos brasileiros confiam nos políticos e 16%, nos partidos políticos. Ainda segundo a pesquisa, Polícia Federal e as Forças Armadas são as instituições mais confiáveis, com a aprovação de, respectivamente, 75,5% e 74,7% dos entrevistados.

O estudo também mostra que 85% acreditam que a corrupção pode ser combatida, e 94,3% acham que um político processado na Justiça não deveria poder concorrer às eleições.

Os entrevistados também consideram importante a reforma política: 95,4% são favoráveis, embora a pesquisa não tenha feito perguntas específicas sobre que mudanças deveriam ser feitas na legislação.

A pesquisa mostra ainda que 79,8% discordam do foro privilegiado para pessoas que ocupam cargos públicos, como previsto atualmente na lei brasileira.

Os dados serão divulgados durante uma audiência pública na Comissão de Participação Legislativa da Câmara dos Deputados, nesta quinta-feira.

A pesquisa foi realizada pela Opinião Consultoria a pedido da AMB e ouviu 2.011 pessoas nas três primeiras semanas de agosto, em entrevistas por telefone, em todos os Estados.

A pesquisa mostra que entre os políticos, o nível local de decisões tem mais credibilidade do que a esfera nacional: 18,9% dos entrevistados disseram confiar na Câmara dos Vereadores, enquanto o Senado Federal tem a confiança de 14,6%, e 12,5% confiam na Câmara dos Deputados.

As questões sobre Justiça também revelam uma confiança maior no âmbito local.

O Poder Judiciário de um modo geral tem a confiança de 41,8% dos entrevistados, mas o Juizado de Pequenas Causas goza de uma confiança maior, de 71,8%. Já os juízes têm a confiança de 45,5% dos entrevistados, e o Supremo Tribunal Federal, a instância máxima do Poder Judiciário, de 52,7%.

Na pergunta sobre qual tribunal é mais confiável, o Tribunal de Pequenas Causas também aparece em primeiro lugar, com 23,6% das respostas. O STF teve 20,5%, a Justiça do Trabalho 19,2% e a Justiça Eleitoral 10,6%.

A grande maioria dos entrevistados declarou já ter ouvido falar do Tribunal de Contas da União (83,6%) e na Controladoria Geral da União (78,2%), órgãos internos de controle do controle do Poder Público, mas uma parcela significativa (43,6%) não sabe a diferença entre o Ministério Público e o Poder Judiciário.

Fonte: http://noticias.uol.com.br/bbc/reporter/2007/09/27/ult4904u193.jhtm

Serie de poemas "Duas palavras uma estação"

Poema 4

Não suspire agora,

A eternidade de um suspiro a outro

Corre o sussurro de meus desejos em teu corpo

Por mais um suspiro e outro

No seu suspirar acelerado

Procurar os lábios secos de paixão

E matar a sede, em seu corpo rubro

Não amar mais que um minuto

E viver em eterna paixão

No revolto desejo

Não mais de amor caíram

Mais que o primeiro beijo

Mais que uma simples tensão

Foge de mim o desejo

Num ultimo suspiro, a ultima canção.

Serie de poemas "Duas palavras uma estação"

Poema 3

Beijo-te a boca cálida

Beijo-te a lua nua

Seco-lhe as gotas da chorosa chuva

Não foi a brisa prazerosa

Que trouxeste seu perfume

Foi a noite escura

Que cobria a pele nua

E trouxera seu amar

Se não foste outro amor

Não seria mais verão

Hei de entristecer a primavera

E amar outro verão.

Serie de poemas "Duas palavras uma estação"

Poema 2

Insensatez eu diria

Acordar contigo em meu peito

Dormindo ainda ao relento

Tão insensato quanto imperfeito

Fazer não por volúpia

Queimar não por prazer

Arder não porque é chama

Cometer pecados, só para viver

Não amas o insensato ao lado

Morrer de amor os insensatos são jurados

Levantar e amar de novo

Cometer o mesmo erro tolo

Não que para amar precise de tato

Apenas para ser mais um insensato

Serie de poemas "Duas palavras uma estação"

Poema 1

Não existe beijo que sacia os lábios desejosos,

Não existe corpo que sacia o toque quente,

Não existe alma que sacia o coração vazio,

Deslizar-te a mão em sua face pálida,

Tocar os lábios, no seu corpo úmido,

Sentir o tremor, do desejo ardente,

Amor? Mais que o calor

Mais que o desejo

Não existe..

Não existe amor que sacia, eternamente....

Gerenciamento de Capacidade para aplicação web – Parte 2

Na parte 1 deste artigo, discutimos a respeito de como entender o comportamento dos usuários e modelá-lo em linguagem matemática para um exemplo de aplicação de ponto, porém o princípio é aplicado a qualquer aplicação, e o que será de extrema valia para quando terminarmos de avaliar o desempenho da aplicação bem como o hardware necessário, pois este conhecimento compilado em uma planilha Excel nos permitirá amanha, em alguma eventualidade fazer de traz para frente às perguntas que passarão a ser mais freqüentes durante a vida útil do sistema: se eu aumentar em 1.000 usuários o sistema, mantendo a infra-estrutura atual, qual será a degradação esperada que obteremos no tempo de resposta? Se adicionar um passo extra no processo de ponto, como sensibilizar uma segunda base de dados, qual será o impacto para o usuário final, bem qual seria o investimento em hardware necessário, e onde especificamente deverei investir, para que amortize essa degradação no tempo de resposta.

Breve consideração sobre virtualização

Quando estamos falando de visão de futuro em TI, onde se busca a construção de uma infra-estrutura de TI que seja capaz de responder em tempo real, ou seja, que a área de tecnologia seja capaz de definir acordos flexíveis de SLA com as áreas de negócio da empresa que dependem de sistemas, ie. definir um tempo de resposta no sistema para usuários e clientes, e em caso de uma situação atípica como uma campanha que aumente a demando do sistema, um ataque DDOS ou qualquer outro evento de demande muito mais do sistema de que ele estava inicialmente desenhado, isto é, buscar resilience.

Com as tecnologias correntes e disseminadas, todo o sistema repousa sobre um hardware monolítico, a aplicação usa todos os recursos que aquela máquina disponibiliza, faltando ou sobrando é o que está alocado estaticamente para aquela aplicação o que nos coloca em posição de lidar com alguns dilemas do tipo: se eu considerar o dimensionamento de hardware para a pior situação e que sua ocorrência seja esporádica e previsível, como declaração de imposto de renda, promoção, natal, etc. estaremos subutilizando nossos recursos computacionais fora destes picos de uso, porém as tecnologias de virtualização estão quebrando este paradigma, colocando a disposição a possibilidades de alterar dinamicamente a alocação de recursos de máquina (eg. CPU, Memória, I/O de disco e rede).

Mesmo com a virtualização a nossa disposição ainda nos falta entender como usá-la como uma arma de gerenciamento de forma efetiva. O bom dimensionamento de capacidade é fundamental para poder avaliar como dividir o hardware físico em partições lógicas para bom dimensionamento de capacidade, e a modelagem desta compilada nos permitirá tomar melhores decisões quando precisarmos rever o SLA.

No futuro teremos ferramentas mais completas, que analisará o histórico de desempenho e poderá predizer de forma mais completa e avaliando um conjunto maior de variáveis qual é a situação atual e qual será a conseqüência “se” isso ou aquilo acontecer, para melhor guiar na tomada de decisão de alocação de recursos de TI, como é o caso do System Center Capacity Planner 2006, porém ele hoje está restrito somente ao Microsoft Operations Manager e ao Microsoft Exchange Server, não lida ainda com a sua aplicação LOB que sua empresa desenvolveu.

A abordagem que apresentamos aqui é uma alternativa razoável e viável para fazer este trabalho do “what-if” de forma satisfatória, utilizando os recursos de TI atualmente disponíveis no mercado e que nos aproxima um pouco mais do nível de maturidade de infra-estrutura virtualizada dentro do modelo do Gartner. (este pode ser o tópico de outro post).

Analisando a Aplicação

O segundo ingrediente na analise de capacidade é conhecer o comportamento da aplicação sob carga, o que nos interessa neste teste é saber qual é o consumo de hardware para a execução de uma “transação”, e para isso iremos precisar primeiro eleger qual ferramenta iremos utilizar para tal, e como já era de se esperar, neste caso vou utilizar o WAST (MS Web Application Stress Tool), primeiro porque é simples, didático e gratuito, só por isso  Depois de definidas as ferramentas, vamos montar o laboratório para analisar a aplicação, e para tanto precisaremos somente de um servidor equipado com caracteristicas semelhantes das que será utilizado na produção, ou seja, se a produção estiver com Xeon 5355 por exemplo, use o mesmo no teste de laboratório, essa é uma recomendação que faço, pois nos dias de hoje, não dá mais para fazer uma simples regra de três com o clock para estimar o desempenho, existe o números de núcleos, o compartilhamento de cache entre os núcles e a microarquitetura do processador que influência no desempenho, portanto a opção de usar o mesmo processador será para eliminar essas variáveis de nossa análise e tornar a “equação” mais simples, o mesmo vale para a configuração de discos e memoria suficiente para não ser gargalo.

Depois do laboratório montado, podemos iniciar os testes de carga sobre o sistema usando o WAST (veja tutorial completo), o resultado final será um relatório gerado pelo WAST em que descreve o resultado do ponto de vista do cliente, ie. quantas requisições ao servidor foram feitas e quantas foram atendidas em qual tempo, quantas não foram respondidas, etc. Outra informação importânte para a nossa análise são os impactos desta carga sobre o servidor, principalmente os seguintes índices:

• Web Service: Get Request/sec

• Web Service: Post Request/sec

• System: % Total processor time

• Active Server Pages: Request/sec

É importante afinar o teste de carga para que o número requisições realizadas pelo cliente não tenham como retorno erros como 404, 400 ou 500, pois significa que o cliente não foi atendido e claramente houveram mais requisições das que o servidor poderia atender, mesmo que o servidor web apresente recursos como CPU, I/O de disco e memória em condição confortável, pois muitos dos problemas que já me defrontei nestas condições apenas escondiam problemas de configuração e ajustes para harmonizar todo o sistema, pois por exemplo: na configuração padrão do IIS, ele permite até 25 threads por núcleo, se a aplicação necessita fazer alguma chamada ao banco de dados ou algum componente externo, aquela thread irá ficar alocada enquanto não houver retorno e a “transação” ser concluida, portanto em casos onde você tenha muitas requisições/segundo e uma lentidão para concluir a “transação”, mesmo tendo CPU disponível, não haverá thread para atender requisições e você receberá um ERRO 500: Server Busy, e portanto será ainda necessário fazer ajustes no IIS para garantir que ele esteja otimizado para as caracteristicas da sua aplicação, para isso recomendo a longa leitura do IIS 6.0 Performance and Tuning ou The Art and Science of Web Server Tuning with Internet Information Services 5.0, porém sem dúvida nenhuma será recompensadora.

Concluindo o teste de carga com sucesso e eliminando todos os problemas de ajustes, será necessário interpretar os dados que temos em mãos. Vamos imaginar hipoteticamente, apenas para trabalhar com um exemplo, que ao final do nosso teste obtivemos o seguinte conjunto de dados:

• System: % Total processor time: 92% na média durante o periodo de testes, com vários picos de 100%. Isso nos permite concluir de forma razoável que houve esgotamente da CPU;

• Active Server Pages: Request/sec: 152, porém para essa aplicação específica, onde é necessário entrar na página, se identificar e selecionar uma ou duas opções antes do POST, requer 8 requisições ASP até completar o processo de “bater o ponto”, portanto temos que é possível neste cenário realizar 19 (152/8) transações por segundo;

Calculando o tempo de resposta

O Teorema Little (LT) define que podemos calcular a capacidade de atender a requisições em uma rede como a razão entre a taxa de requisições sobre a taxa de requisições que podem ser processadas. Se o sistema chega a um ponto onde a razão se torna maior que 1, então nós excedemos a capacidade de atender mais requisições, portanto ou perderemos a requisições (Erro 500) ou teremos que enfileirá-la para ser atendida em algum momento. Portanto podemos com isso definir em que ponto o nosso sistema irá falhar. Se definirmos algum enfileiramento , a razão poderá exceder até o ponto onde houver cache para aceitar requisições, e eventualmente essa razão voltar a ficar abaixo de 1 por tempo suficiente para liberar o cache. Se na média durante o tempo essa taxa exceder a 1, o sistema irá começar a recusar requisições.

A figura abaixo determina o número de requisições que podem ser mantidas na fila e o tempo que uma requisição precisará esperar para ser atendida

Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento de requisições, p=λ/μ ).

É neste ponto onde a probabilidade de Poisson se torna realmente útil. Podemos selecionar a taxa de requisições baseado na probabilidade de multiplos usuários acessarem o sistema simultaneamente, onde só com a média de requisições que encontramos com a curva de Gauss, porém não nos dava o pior caso que é exatamente o que procuramos. Agora podemos prever não só a média de requisições que podemos atender bem como tempo máximo que o usuário precisará esperar para que a requisições seja atendida.

Definindo o Ambiente:

Chegando a esse ponto já temos bastante informação a respeito de como funciona o sistema e como ele se comporta sob carga, portando concluimos a seguinte tabela e seu gráfico correspondente:

Sabemos ainda que pela probabilidade de Poisson, termos 19 usuários simultaneos requisitando o registro de ponto é de 1x10^-14 em termos percentuais, portanto acho que podemos considerar “pouco provável” :) Infelizmente o nosso trabalho muitas vezes não pára por aqui, pois se for necessário dimensionar o sistema para um número maior de usuários, por exemplo, será ainda necessário nos testes de carga determinar se o sistema consegue escalar linearmente com o aumento de processadores/máquinas, o que normalmente ocorre com aplicações stateless, ou se haverá penalidades, o que pode ocorrer em situações onde você tem um banco de dados ou um componentes que represente um gargalo na transação.

Bem… gerenciamento de capacidade é uma tarefa contínua e não existe regras fixas, mas sim boas práticas, das quais procurei nestes dois posts do blog compartilhar um pouco com vocês.

Texto retirado de: http://blogs.intel.com/brasildigital/2007/09/gerenciamento_de_capacidade_pa_1.html

Gerenciamento de Capacidade para aplicação web – Parte 1

comentado por Bruno Domingues em agosto 3, 2007

Depois de algum tempo resistindo a criar um blog, eu me rendi a essa oportunidade de escrever aqui no blog da Intel em nossa língua pátria. Meu nome é Bruno Domingues, tenho 28 anos, moro em Brasília e trabalho no segmento de governo da Intel, como Especialista de Soluções. Trago uma experiência de 8 anos em função similar na Microsoft, portanto esperem muitos exemplos e comentários nesta plataforma, pelo menos até perder o “vício”.

Vou procurar postar aqui tanto os meus comentários a respeito de notícias, tecnologia e links que eu julgar interessante, sempre do meu ponto de vista, que algumas vezes pode não ser o ponto de vista da Intel, afinal este é um blog. Tenho especial interesse em arquitetura e governança de TI, virtualização, gerenciamento de capacidade/avaliação de desempenho e segurança de forma geral.

Comentários são sempre bem vindos, e pelo fato de estar quase sempre conectado não se assustem se eu responder rapidamente.

Após minha apresentação como preâmbulo, vamos ao que nos interessa: gerenciamento de capacidade para aplicações web.

A arte de estimar a infra-estrutura necessária para uma dada aplicação web pode ser uma tarefa ardilosa se você tem o orçamento restrito, precisa acertar na primeira vez e sua empresa tem grandes expectativas no sucesso do empreendimento, sem muita margem de manobra para qual configuração apostar.

Os primeiros passos a serem dados nesta direção serão conhecer o comportamento dos seus usuários, ou pelo menos tentar predizê-lo, e também conhecer sua aplicação, ie. funcionamento, consumo de recursos computacionais, tempo de resposta, comportamento em sessões concorrentes etc…

Conhecendo o seu usuário:

O primeiro passo para um bom planejamento de capacidade, começa em conhecer bem o seu usuário, quando ele acessa o seu sistema, por quanto tempo ele permanece interagindo com a aplicação bem como ele interage e, mais importante de tudo, qual o tempo de resposta que ele espera.

Para ser didático, vamos trabalhar com o exemplo de uma aplicação de ponto, onde cada funcionário da sua empresa irá precisar efetuar logon na aplicação e dar aceite no horário que estará sendo apresentado na aplicação, porém neste momento vamos abstrair um pouco os detalhes da aplicação e vamos nos concentrar nos usuários.

Pelo fato da aplicação ser um sistema de ponto, é de se esperar que os usuários tenham seus picos de utilização no inicio da manhã quando estão chegando ao trabalho, no período de almoço e ao final do dia. Vamos aqui a título de ilustração assumir que a empresa tenha 5.000 funcionários e que obviamente nem todos efetuam logon ao mesmo tempo em suas estações de trabalho, pois sempre há os atrasados, aqueles que chegam mais cedo por deixarem primeiro os filhos na escola, tem o tempo do elevador, do café e de estacionar o carro, o que faz com que tenhamos uma distribuição no tempo do acesso destes usuários ao sistema, o que nos faz pelo bom senso desprezar a pior das situações, que seria 5.000 usuários acessando ao mesmo tempo o sistema, porém se a pior situação não é ter 5.000 usuários pendurados ao mesmo tempo no sistema, qual seria o razoável?

Para responder a essa pergunta pode-se estimar o pico de acesso dos usuários usando a curva Gauss, pois é um modelo que parece aderir bem à natureza do problema e dai já é o ponto de partida para criar o jogo de “what-if”.

A figura 1 representa o gráfico de uma razoável predição do comportamento de hits no sistema em um dia útil, e permite facilmente deduzir porque usar a curva de Gauss para modelar a carga no site web.

Embora o conjunto de dados levantados me traga os dados em horas, o que realmente importa aqui é quanto tempo o usuário precisará esperar para o servidor responder, ou pela lógica reversa, qual será o hardware necessário para que o usuário tenha resposta em até um tempo limite, considerado máximo (assumindo que não há otimizações a serem realizadas na aplicação), portanto é preciso calcular o número de hits/segundo no pico da nossa curva.

Para tal, vejamos a figura 2 que representa a equação da curva de Gauss. A variável y representa o número de usuários em um determinado momento e σ é o desvio padrão. Para aqueles que não têm dedicado muito tempo a estatística ou já não se recordam muito a este respeito, o desvio padrão representa a distância do centro da curva que contém 68% dos elementos do conjunto. Em se movendo três vezes o desvio padrão do centro da curva, 99,7% dos elementos estarão cobertos. O símbolo µ é a localização do centro da curva ou a média. x representa o número de elementos a direita ou esquerda da média.

A curva de Gauss precisa agora estar aderente a nossa estimativa, para tanto é necessário multiplicar a unidade da curva pelas requisições estimadas, e ainda deve-se trabalhar o desvio padrão para obter maior aderência ao conjunto de dados. O resultado final, portanto é a freqüência de usuários por segundo no ponto médio da curva, conforme apresentado na figura 3, onde usei uma planilha eletrônica para realizar tais manipulações estatísticas.

Olhando para o sistema de ponto com mais critério, parece muito ingênuo pensar que uma empresa com 5.000 funcionários de fato tenha em algum dia do ano 5.000 funcionários trabalhando num dado dia, pois existem as férias, licença-médica, maternidade, treinamento, viagem de negócio, trabalho externo etc. portanto vamos adotar de forma “heurística” um ponto de corte conservador, imaginemos 80% dos contribuintes da empresa, ie. 4.000 funcionários, que seria neste caso pior cenário. Mas, para se chegar a estimativa de usuários simultâneos acessando o sistema, iremos recorrer a outra ferramenta de probabilidade e estatística: a distribuição de Poisson.

Poisson é um dos métodos para modelar o uso. A teoria por trás da probabilidade de Poisson é que as requisições ao sistema obedecem a uma curva exponencial para solicitações simultânea de outros usuários. Usando a média, que encontramos na curva de Gauss (1,22 usuários/segundo em média) há uma alta probabilidade que 0, 1, 2 e 3 usuários acessem o sistema simultaneamente com o período de tempo escolhido, porém a probabilidade de seis ou mais usuários acessando o sistema simultaneamente cai drasticamente, conforme figura 4.

Na figura 5, µ é a média do número de usuários requisitando acesso ao site por unidade de tempo. Este número é derivado da fórmula de Gauss. O termo x se refere ao número de usuários entrando no sistema no período.

Podemos utilizar uma planilha eletrônica comum novamente para nos prover a distribuição de Poisson não cumulativa, conforme apresentado na figura 6.

Agora que chegamos a estimativa da razão de acesso, que modela em primeiro nível o lado dos usuários, devemos prestar atenção agora para o lado do servidor, ie. aplicação e hardware para completar o tripé que dão base a qualquer gerenciamento de capacidade, porém este será o tema da parte 2 deste assunto.

Texto retirado: http://blogs.intel.com/brasildigital/2007/08/gerenciamento_de_capacidade_pa.html