Highrise (Gerenciador de Contatos)
- 3,5 milhões de contatos
- 1,2 milhões de anotações/comentários
- 0,5 milhão de tarefas
Backpack (Organizador Pessoal)
- Quase 1 milhão de páginas
- 6,8 milhões de to-dos
- 1,5 milhão de anotações
- 0,8 milhão de fotos
- 0,3 milhão de arquivos
No geral, isso vale o seguinte (Nov. 2007:
- 5,9 terabytes de arquivos
- 0,8 terabytes de uploads
- 2,0 terabytes de downloads
- 30 máquinas, 100 CPUs, mais de 200Gb de RAM
Ele farão um upgrade de hardware em breve para passar a ter:
- 16 máquinas, 92 CPUs, mais de 230Gb de RAM
Não se enganem, isso é bastante coisa para administrar. A primeira etapa de colocar tudo no ar é a pior, depois disso, no geral, escalar passa a ser “simplesmente” (entre aspas) adicionar um slice extra (no caso de box Linux virtualizado com Xen) ou adicionar uma máquina extra. Deployment também, uma vez configurado, é uma “simples” tarefa para o Capistrano. Imagino como deve ser o dia-a-dia de um sysadmin numa configuração dessas. Fora outras tarefas paralelas como segurança, fail-over, etc.
E não deixem de ler a entrevista com David Hansson publicada na InfoQ a respeito do Rails 2.0.
Falando em milhões, numa nota adicional, a Apple já vendeu este ano 5 milhões de iPhones. Em janeiro deste ano, quando anunciou o lançamento para junho, a meta de Steve era 10 milhões de iPhones vendidos até o fim de 2008. Ele já alcançou metade dessa meta, em 6 meses, e ainda nem entrou direito na Europa e outros mercados ávidos por gadgets como Japão. Muitos analistas agora estão chutando alto, como 50 milhões vendidos até 2009. 1 ano atrás esse número seria ignorado, hoje ela parece mais e mais uma realidade.
Dentre outros números, nos Estados Unidos, o iPhone já vende mais que os devices baseados em Windows Mobile, ou Symbian, a caminho de morder os Blackberry. Em 6 meses já é 1 terço do market-share norte-americano. Por que isso é importante para nós, web developers? Porque o Mobile Safari é hoje o browser móvel mais usado. É o único que efetivamente permite uma navegação web móvel decente (e eis porque não interessa hoje ser 2.5 EDGE e não 3G – veja a comparação de um site alemão sobre o iPhone vs um Nokia 3G). E para os interessados em Android recomendo o artigo The Great Google gPhone Myth. O Android será um excelente OS para os smartphones ‘affordables’.
Aliás, já recomendei antes e recomendo novamente os artigos de Daniel Eran do RoughlyDrafted como uma ótima fonte de leitura – imparcial – mas bem argumentada, densa em informações e divertida, com alguns pontos de vista bem pouco ortodoxos :-)
E falando em futuro, Tim Bray, da Sun, publicou um micro-teste pessoal que ele fez com um script para analisar logs (pesado em I/O e Regex). Daí ele publicou os resultados de rodar o mesmo script no Ruby MRI 1.8, Ruby MRI 1.9, JRuby trunk e JRuby 1.1b. Eis os resultados:
| Elapsed | User | System | |
| Ruby 1.8.6 | 59.6 | 58.8 | 0.8 |
| Ruby 1.9 | 59.9 | 58.8 | 0.8 |
| JRuby 1.1b | 62.5 | 63.4 | 1.3 |
| JRuby trunk | 43.5 | 44.5 | 1.0 |
Segundo Charles Nutter essa grande diferença no JRuby trunk é devido à nova implementação de um engine Regex baseado em bytes, o Oniguruma (para quem não sabe japonês, ‘oni-kuruma’ literalmente quer dizer ‘carro-do-diabo’, não me perguntem o motivo, mas é engraçado :-) De qualquer forma apenas isso representou um ganho de quase 30% em relação ao MRI, e isso porque ainda tem muito mais otimizações a serem feitas.
Continuando a falar de Tim Bray, ele teceu alguns comentários sobre Erlang. Assim como a maioria de nós ele é um pragmático. Erlang ganhou muita atenção desde que os Pragmatic Programmer lançaram seu livro sobre ele. Essa linguagem criada na Ericsson mostra sua idade, a maioria dos programadores não gostam muito da sua sintaxe (aprendemos muitas técnicas novas nos últimos 20 anos que não existem em Erlang) mas por outro lado ela tem algo que a maioria das linguagens não tem: processamento-paralelo-massivo-através-de-primitivas-baratas-de-processos-e-comunicação-assíncrona-via mensagens-sem-uso-de-memória-compartilhada.
Resumindo: processamento paralelo sem as dores de cabeça de threads. Primeiro, vale a pena ler sobre o prof. Edward A. Lee e porque threads são consideradas ruins. Threads usam memória compartilhada, não são determinísticas e é a fonte dos bugs mais chatos para debugar. Por outro lado processos rodam isoladamente, paralelamente e de maneira previsível. O problema: na maioria das linguagens, processos são muito mais ‘pesados’ do que threads, por isso prefere-se o segundo. Porém, linguagens como Erlang nos provocaram a buscar métodos melhores para lidar com paralelismo. Ele não resolve todos os problemas mas é uma direção interessante a se seguir para o futuro. Tim Bray gostaria de ver essas primitivas em Java ou Ruby – eu também.
O assunto de Erlang surgiu forte esta semana justamente por causa dos rumores de que o Amazon Simple DB que eu expliquei num outro artigo poderia ter sido escrito em Erlang, assim como seu primo CouchDB.
Sobre paralelismo, sabemos que o Google atacou o problema e saiu com o seu famoso sistema de MapReduce para processamento paralelo massivo. Na realidade o Google não “inventou” o Map/Reduce. Qualquer um que tenha estudado Ciência da Computação conhece esses dois conceitos simples de linguagens funcionais como Lisp. Existe inclusive uma versão de MapReduce em Ruby que recomendo estudar: chama-se Starfish e inclusive utiliza ActiveRecord o que deve tornar as coisas mais confortável para Railers. É um pouco diferente do que já tínhamos com Drb e Rinda.
Em tempos de Multi-code, virtualização, paralelismo é o assunto quente em desenvolvimento de software. Eu particularmente espero que threads tenham seu uso diminuído drasticamente em favor de processos assíncronos.