Site menu:

Categorias

 

setembro 2010
D S T Q Q S S
« out    
 1234
567891011
12131415161718
19202122232425
2627282930  

Outros

RSS Antonio Anderson

RSS Plantão Info

Site search

Histórico

RSS Blog do Ensinar

Valid XHTML 1.1

Valid CSS 2.1

Rails Summit LA 2008 by Locaweb – Dia 15

Olá gente!

Nos dias 15 e 16 de outubro de 2008, no auditório Elis Regina, estava eu no evento Rails Summit LA, organizado pela Locaweb. Foram também alguns colegas de trabalho (Voice Technology), Vitor Martinez e Noel Rocha, onde nos divertimos muito, demos muita risada, e além de tudo, aprendemos coisas legais e interessantes sobre Ruby e derivados.

Primeiramente gostaria de parabénizar o pessoal da Locaweb, e também Fábio Akita, o principal evangelizador no Brasil, e também referência em RubyOnRails. Lembrando que a Rails Summit foi inspirada na RailsConf.

Neste evento, foram realizadas muitas palestras, todas muito interessantes, porém não deu para assistir todas, pois algumas aconteciam simultâneamente, em auditórios separados.

A primeira palestra, de abertura, foi de Gilberto Mautner, fundador da Locaweb, que apresentou o início da Locaweb, onde seu primo tinha uma fábrica de produtos têxtil, e Gilberto criou um site para ela, em ASP, que foi onde tudo começou: o site não deu certo, mas um problema que eles haviam tido, foi que era difícil encontrar servidores de hospedagem no Brasil, assim, Gilberto e seu primo tiveram a idéia de, finalmente, criar a Locaweb. Após isso, Fábio Akita continuou com a abertura.

Após isso, tivemos a palestra de Chad Fowler, um dos fundadores da RubyCentral, disse sobre um de seus livros, o My Job Went to India, e também comentou bastante sobre a evolução de um framework, e pedia para que os usuários de Ruby, o use com cuidado(?).

Após, tivemos a participação virtual de David Heinemeir Hansson, o criador do Rails, através do telão, que comentou bastante sobre a tecnologia do Rails e muitas coisas sobre a nova versão 2.1, e respondeu perguntas sobre performance, thread-safe e acesso à vários bancos-de-dados.

Tivemos também uma palestra de Fábio Akita, que explicou noções básicas de Ruby, abordando os comandos básicos da linguagem (se alguém lembrar de algo mais, comente, pois não participei desta palestra =[ ).

E também tivemos uma palestra de George Malamidis, que trabalha na ThoughtWorks, que explicou algumas coisas sobre escalabilidade, Rest no Rails, com RESTful, estados Statefull e Stateless, o uso de protocolos quanto à capacidade, carga e performance (HTTP, BitTorrent, SMTP, FTP e XMPP) e alguns outros assuntos da Web 2.0.

Dr. Nic Williams e Caio Quirino

Dr. Nic Williams e Caio Quirino

E agora, a palestra de Dr. Nic Williams, a qual gostei muito, que falou sobre muitos assuntos, como a utilização do git, sua participação no mundo open-source, explicou como complementar uma página ou um blog com comentários usando uma biblioteca pronta ou códigos javascript, e mais alguns outros assuntos. Disse que quando era mais novo, queria ser hacker de carros, mas não podia, pois os pais dele usavam o carro; queria ser hacker de máquina, mas não sabia o que fazer com as peças e componentes; e finalmente quiz ser hacker de códigos, e isso sim ele pode fazer o quanto quizer, pois é uma coisa bastante acessível.

Como algumas palestras aconteciam simultâneamente, não tenho informações de como foi a palestra de Carlos Brando, da SurgeWorks LLC, que mantém o blog http://www.nomedojogo.com/ e ajuda na comunidade, como na tradução de um livro, o Why’s Poignant Guide to Ruby.

A última palestra do dia foi realizada por Chris Wanstrath, o criador de um repositório de projetos, com grande massa de projetos open-source, o github.com, que foi aberto no meio do ano passado e já é muito utilizado pela comunidade open-source, e pela comunidade ruby. Chris disse sobre como foi o início do site, e também algumas coisas de como ele funciona.

E, por ultimo, tivemos o “Birds of a Feather”, uma desconferência, onde os participantes podem falar sobre um tema que achou interessante e gostaria de compartilhar com todos, com muitas perguntas e participação.

Obrigado a todos, em breve postarei um outro post com o segundo dia da Rails Summit.
Até Mais.

-

Dica: Para quem desenvolve em Ruby com o eclipse ou NetBeans, existe um interessante plugin para desenvolver Ruby e Rails (e outras linguagens, como o PHP, por exemplo): o Aptana Studio.

Página do evento e fonte: http://www.locaweb.com.br/railssummit/

Regras para testes automatizados de Performance

Olá gente, hoje estou afim de compartilhar meu conhecimento de testes automatizados de performance, e conceitos de testes exaustivos.

Em plataformas de testes automatizados onde cada thread deverá ter uma configuração diferente da outra, obviamente não podemos executar duas threads iguais simultaneamente, para isso temos duas formas para a execução e medição dos testes:

1 – Medição de testes por execução de threads/segundo

A medição de testes baseada em threads por segundo visa iniciar coordenadamente o teste, porém se a duração de cada teste for maior do que o tempo planejado, poderá haver um “encavalamento” dos testes, isto é, a mesma configuração ou até a mesma thread pode estar sendo executada simultaneamente, assim quebrando toda a infra-estrutura do teste. Uma boa forma de evitar isso é deixar, sempre que possível, threads sobrando, para, se acontecer, apenas afetar a próxima thread, que deverá estar ociosa.

Para a medição de testes baseada em threads/segundo, devemos ter dois valores:

  1. O tempo de rump-up ou o número de threads/segundo.
  2. O número mínimo de threads ou a duração máxima.


Legenda:

R = Rump-up (segundos).
Tr = Número mínimo de threads.
D = Duração máxima (segundos).
Ts = Threads/segundo.

Sendo que:

  • Ts = 1 / R
  • R   = 1 / Ts
Procedimentos:

Tr = D * Ts
D   = Tr / Ts

Assim, concluímos que:

  • Para obtermos o número mínimo de threads, precisamos conhecer a duração máxima do teste e a quantidade de threads iniciadas por segundo, e multiplicá-los.
  • Para obtermos a duração máxima do teste, precisamos conhecer o número mínimo de threads e a quantidade de threads iniciadas por segundo, e multiplicá-los.
  • Para obtermos a quantidade total de testes executados, precisamos conhecer a duração total de execução dos testes em segundos, e multiplicar pela quantidade de threads por segundo.


2 – Medição de testes por Thread Pool

A medição de testes baseada em Thread Pool visa apenas garantir que o teste está rodando simultâneamente por todos os threads de uma Thread Pool, assim não se corre riscos de encavalamento de threads, porém esta forma pode ser mais difícil para criar estatísticas, pois se todas as threads já estão sendo utilizadas, a plataforma de testes espera alguma thread ficar ociosa para iniciar outro teste nela, e desta forma não é possível determinar a quantidade exata de testes executados em um determinado período de tempo, pois o tempo de rump-up de cada teste se torna indeterminado.

Para a medição de testes baseada em Thread Pool, devemos ter 3 valores:

  1. O número de threads / tamanho da thread pool.
  2. A duração do teste.
  3. O intervalo entre o fim de um teste e o início do próximo teste (por thread).
Legenda:
T = Número de threads / tamanho da thread pool.
D = Duração do teste (segundos).
I = Intervalo entre o fim de um teste e o início do próximo teste (por thread).

Procedimentos:
D + I = Tempo estimado por teste (segundos).

Assim, concluímos que:

  • Somando a duração do teste, o intervalo entre o fim de um teste e o início do próximo teste e o tempo de rump-up, temos o tempo estimado por teste.
  • Para obtermos a quantidade estimada de testes executados, devemos dividir a duração total da execução dos testes em segundos pelo tempo estimado por teste em segundos, e multiplicar pelo tamanho da thread pool.

Bom, esta é uma parte da minha experiência com testes automatizados, espero que seja conceitual e faça sentido, pois é apenas a minha opinião. =]

Tchau gente!

Garbage Collection

Olá gente, irei abordar à vocês um pouco do que sei sobre o “Lixeiro” do Java (famoso GC), o Garbage Collector, que é um processo/serviço de gerenciamento de memória, responsável por limpar dados que não serão mais usados, pois sem a ajuda dele, ou teremos de limpar a memória “manualmente” ou teremos o esgotamento da memória.

Geralmente acontece em C, C++ e Pascal de, além de poder acumular objetos sem referência na memória e ocorrer o esgotamento da mesma, ao limpar manualmente, também pode-se acontecer de limpar da memória objetos ainda em uso. Quando bem feita a limpeza de objetos sem referência em linguagens que não possuem o garbage collector, a aplicação tende à ter mais performance em relação à uma outra feita da mesma forma, só que com a coleta feita automáticamente (com o garbage collector). No C por exemplo, para limpar da memória a variável x, devemos executar ao fim do seu uso, o comando free em seu ponteiro. ( ex.: free(*x); ).

Um assunto que dá muita dor-de-cabeça é o Memory Leak, que seriam pontos do sistema onde temos um “vazamento de memória”, que apesar de acontecer com menos frequência em sistemas feitos por linguagens com o garbage collector, um memory leak pode acontecer por falhas na arquitetura do sistema como referências à objetos desnecessários.

A performance de um sistema está ligado ao custo da alocação e desalocação de memória e à quantidade e complexidade de processamento de informações. Os objetos só são descartados da memória quando eles perdem 100% a sua referência.

No Java, temos a JVM(Java Virtual Machine), que é responsável pela alocação de todos os objetos de uma aplicação na memória, e pela separação de processos que são de aplicações diferentes, além de outras coisas.
À cada execução de um programa feito em Java, temos uma nova JVM aberta, mesmo quando abrimos mais de um programa ao mesmo tempo.
Nela, temos o Heap space, que seria o tamanho, ou a “área” da memória que podemos utilizar em cada JVM, que é determinado pelo espaço mínimo e pelo espaço máximo que poderá ser alocado para a JVM.

Ao medir a performance em sistemas com garbage collection, temos alguns termos:
Throughput:
A porcentagem de todo o tempo não-utilizado pelo garbage collection, consideirado à partir de um longo período de tempo.
Garbage Collection Overhead: O inverso de Throughput, é a porcentagem de todo o tempo utilizado pelo garbage collection.
Pause Time(Tempo de Pausa): A duração do tempo em que o processamento da aplicação é pausado para a ocorrência do garbage collection.
Frequency of Collection(Frequência de coleção): Fator quantidade/tempo em que a coleção é feita, relativa à execução da aplicação.
Footprint: Menciona o tamanho da Heap.
Promptness: O tempo de duração desde quando um objeto perde todas as referências (se torna “lixo”) até quando a memória se torna novamente livre dele.

No java, ao executar um programa, podemos usar, por exemplo, algumas funções abaixo, além de muitas outras:

-Xms[Tamanho] e -Xmx[Tamanho]: onde temos [Tamanho], temos de substituí-lo pelo tamanho especificado em megabytes, seguido por m (há também outras medidas para alocação da Heap).

Por enquanto é isso, espero posteriormente poder explicar como coletamos dumps/snapshots do Heap da JVM e analizamos um vazamento de memória. (Mas antes, tenho de aprender como faz… hehehe).

Espero que tenham gostado, aceito dicas, críticas e sugestões!

Fonte:

http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
http://www.javafree.org/javabb/viewtopic.jbb?t=1386

Saudações à todos

Olá galera!

Estou iniciando este blog que planejo postar matérias sobre Informática, sobre Música, sobre mim e o que eu achar interessante para compartilhar com todos vocês!

Fico muito feliz por ter criado este blog, pois pode ser a porta de entrada para uma vida mais formal, e isso pode ser muito interessante para todos!

Primeiramente gostaria de agradecer à toda minha família, que sempre está me apoiando e me corrigindo em todas as ocasiões, que é o que faz com que eu cresça e saiba o que fazer mesmo nas horas que não estou junto à eles! Obrigado Deus, Pai, Mãe, Igor, Ramon, Lucas e amigos por sermos tão unidos e sempre ajudando uns aos outros!

Gostaria de agradecer também ao meu professor da Caelum, o Ricardo Nakamura, que me deu dicas de como iniciar com um blog. Além disso, e o mais importante, foi ele quem me treinou para o exame 310-065(Java 6) (ainda não fiz a prova), ele é um excelente professor, explica muito bem e entende muitooo sobre java! Seria um prazer tê-lo como amigo!

Agradeço também ao pessoal da Voice Technology que convivo há um ano, que também são muito importantes para mim!

Para quem não me conhece, eu sou o Caio Quirino da Silva, moro em São Paulo, tenho 17 anos, estudo informática há uns quatro anos, sou bastante curioso, gosto de todos os tipos de música, e principalmente de trocar idéias sobre todos os assuntos!

Yeah! Espero que tenham gostado!

Valeu gente!!!