performance vc pode ler de duas formas
1- o tempo TOTAL (tempo fim - tempo inicio) é menor
2- o uso dos recursos da minha maquina (tempo de cpu, memoria, etc) é menor
se for o primeiro caso, a resposta não é simples. veja só
processo1 | processo2
vc tem 2 processos conectados por um named pipe. o processo2 fica bloqueado ate que o processo1 escreva. enquanto existe um bloqueio o escalonador vai fazer outras coisas (como executar o processo1, ou o processo3, 4, 999).
mas o IO que existe entre os dois processos, via de regra, é IO Bufferizado em memória. é totalmente diferente de
processo1 > arquivo ; processo2 < arquivo
nesse ponto vc sente o poder do sistema operacional: na segunda etapa vc pode simplesmente LER de um cache em memoria ao inves de ler do disco fisico. e o processo de escrita nem sempre é controlado pela CPU pois ela vai usar DMA pra escrever em disco. O ponto que eu quero chegar é que IO é uma grande inimigo da performance, por isso vc precisa usar de forma inteligente. quanto menos overhead, melhor. afinal
processo1 | processo2
tem menos overhead do que
p1 | p2 | p3 | ... | p999
Mas IO Bloqueia. e quando bloqueia o escalonador vai fazer algo de util. o que vc poderia fazer para bloquear "menos"? dentro da mesma maquina, as tecnicas que existem não surtem muito efeito. se fossem 2 maquinas, por exemplo, falando através de rede ai sim vc poderia fazer coisas divertidas. mas é a mesma maquina. o SO vai fazer um trabalho soberbo pra isso ser eficiente. no maximo vc pode fazer teste com alguns parametros do SO para ver se no seu problema especifico vc pode ter alguma melhoria, mas lembrando que a sua maquina vai fazer 3983274923784 outras coisas também.
Vamos para o item 2. o que seria um uso mais racional dos meus recursos? ora imagine o seguinte
processo1 | processo2
imagine que o buffer é de 1 MB e vc jogou 1GB de dados. vc lotou o buffer 1024 vezes (grosso modo) e o processo1 bloqueou 1024 vezes (grosso modo), para que o processo2 lesse os dados. a soma desses 1024 bloqueios no final podem ser acrescidos de mais alguns delays e vai demorar. por outro lado, o processo2 pode ser um grep (procurando a string foo) e suas linhas tem aproximadamente 80 bytes. se o grep for mal implementado, vc vai perder ciclos de cpu procurando a string foo.
vc pode fazer duas coisas:
1- usar um grep "melhor", que gaste menos cpu
2- paralelizar
imagine q vc tem uma maquina poderosa com 16 nucleos. 16 processos simultaneos podem ser executados. vc poderia ter 1 processo1 e uns 10 greps em paralelos, pegando pedaços dos dados. fica MAIS complexo, porem vc usa de forma mais racional a maquina.
paralelizar tem suas pegadinhas
1- o custo de gerenciar isso tudo pode ser alto
2- nao necessariamente vc pode paralelizar
3- vc vai ter q juntar os dados
4- o tempo do grep pode não ser o problema.
para coisas mais divertidas, contas as ocorrencias de uma palavra, fica mais evidente.
cat arquivo | sort | uniq -c
pra um arquivo com 100 palavras, ninguem percebe isso como sendo ineficiente. agora imagine 100 terabytes de dados. para estes problemas vc tem soluções como Hadoop e certamente vai usar mais de uma maquina.
Meu resumo:
1- temos q entender o gargalo. é cpu? é IO?
2- se for cpu, podemos usar um algoritmo mais eficiente?
2a- se for cpu, podemos usar um algoritmo com menos overhead
3- se for IO, o que podemos fazer?
um pipe é um tipo de IO muito eficiente. para ESTE ser o gargalo vc tem alguma condição muito peculiar
a- a maquina esta fazendo MUITA coisa
b- são MUITOS dados
c- são MUITOS pipes
é por este motivo q é interessante vc usar um servidor de log. envie os logs da applicação por UDP e vc pode brincar com o log em outra maquina dedicada para isso.
é por esta razão que não se deixa a maquina fazer swap: vc vai fazer IO em disco para trabalhar com memoria e la se vai a performance DE TUDO.
é por esta razão que mais vale vc usar algo como o STATSD para estatisticas do seu sistema. envie os dados brutos e faça as contas em outro lugar (medias e outras coisas).
numa cloud vc tem algumas facilidades para utilizar servidores diferentes. Usar o S3 da amazon dentro de uma maquina no EC2 vai ser mais eficiente. Basta medir.
otimização prematura é suicidio. sem entender o problema não otimize nada a menos q seja algo obvio (como cache de imagens em um servidor web).
só usar memoria não é a resposta. o tempo de acesso a RAM pode não ser aceitavel em algum momento. fora q RAM é algo q tem limite, etc.
vou dizer que nos nosso dia a dia uns 90% de tudo não precisa ter performance. não vale a pena. vc vai gastar mais do SEU tempo do que o tempo que vc vai economizar na cpu. dicas como
ao inves de
cat arquivo | grep
usar
grep arquivo
vai te salvar a vida em alguns outros momentos.
o grande resumo final que eu posso fazer é: antes de pensar em performance temos q entender o que ha por traz da abstração que estamos utilizando. imagine q eu diga q fazer
processo1 $#$%$#%$#@%%$@$ processo2
é mais rapido q um pipe. WOW. mas 99% das pessoas não sabe o que é isso. resultado: um dia outra pessoa vai dar manutenção nisso e vai ter dores de cabeça. o pipe é uma abstração util que resolve uns 95% dos casos. casos extra precisam de mais atenção e precisam ser documentados.
espero q este email seja util pra alguem.
Tiago