[FUGSPBR] benchmark

[Gustavo Vieira Goncalves Coelho Rios]

On Fri, Jun 22, 2001 at 07:01:06PM -0300, guilherme komel wrote:
>
>Pessoal,
>
>
>sei que o assunto e meio off-topic, mas semana que vem a IBM tá me enviando
>uma R6000 pra eu "brincar" e ver como a coisa funciona...
>
>pretendo instalar além do AIX, ou Linux PPC e netBSD - bad news, no FreeBSD
>port yet.
>
>mas a minha idéia é poder testar o desempenho de algumas aplicações, como
>Apache, Websphere, DB2, Oracle, MySQL e PostGreSQL e poder comparar o
>desempenho com uma máquina x86 rodando Windows, FreeBSD e Linux.
>
>não é só, depois eu vou ter acesso a uma Sun r220 com 18Gb HD, 2
>processadores e 2 Gb RAM para poder executar os mesmos testes.
>
>desta forma eu pretendo ter algo bem concreto sobre como cada SO se comporta
>em cada plataforma, além de saber dimensionar soluções muito melhor.

Ola Guilherme,

Para conhecer o impacto que uma variavel gera na sua funcao, voce deve alterar apenas a variavel que voce deseja conhecer.

Se quiser conhecer o compartamento do SO, entao meu caro, troque de SO, porem use o mesmo hardware, tudo bem igual. Todo mundo que um SO rapido, porem o que poucos sabem que o sistema de arquivo tem impacto fundamental na performance. A segunda coisa a se conhecer eh como se o SO realiza a gerencia de memoria, eh fundamental uma boa gerencia.

Para testar o sistema de arquivo, procure realizar operacoes de IO. Mas antes considera duas coisas:

1) o IO deve ser realizado em blocos de dados do mesmo tamanho do bloco da particao, ou seja, para alocar o buffer com o tamanho exato voce tera de saber o tamanho do bloco do arquivo no qual estara fazendo IO. Use a funcao stat para lhe retornar um estrutura que contenha entre outras coisas o tamanho preferencial do bloco. O nome do campo eh st_blksize. Seu buffer deve ter este tamanho.

2) Outro fator importante eh quanto ao alinhamento do operacao de IO. Imagine a seguinte situacao: Suponha que o tamanho de seu bloco para um dado arquivo no sistema eh 8192 bytes. Obviamente, voce devera alocar um buffer de 8192 bytes. Ou seja a cada operacao de leitura/escrita no arquivo sera em "chuncks" de 8192 bytes.Isto pode lhe garantir a melhor performance? NEM SEMPRE.

Ok: estamos lendo em blocos de 8192 bytes, porem imagime que voce esta no offset 3000 do seu arquivo (voce usou a api lseek). Agora voce tem um problema. Quando sua operacao de io for realizada voce lera 8192 porem a partir da posicao 3000. O KERNEL trara 16384 bytes para o buffer interno, pois ele nao pode ler "quebrado", ou seja, serao tragos os dados na posicao 0 ate 8191 e da posicao 8192 ate 16383, porque simplesmente voce realizado uma leitura que possui uma interccao entre dois blocos. Embora dois blocos sejam tragos para a memoria, apenas os bytes da posicao 3000 a 11191 inclusive serao copiados para seu buffer. Entendeu.

Portanto para testar seu SO, realize IO em blocos do mesmo tamanho do bloco do arquivo para o dado FS e nao realize operacoes que possam atrapalhar o alinhamento.



Ja na parte de MM, voce deve criar alguns processos que aumente a troca de contexto no sistema e depois obter o timing deles. Se poder alocar memoria e desalocar a doidado, so para ver como ele gerencia os "gaps" melhor ainda. Quando mais voce baguncar a sua memoria gerando gaps, mais vezes o SO tera que fazer garbage collection, ou seja, o SO gastara mais tempo realizando processamento para manutencao do sistem como um todo do que procesando coisa "util", i.e., tarefas de usuario.


Tem tambem a parte de TCP/IP, porem nao tenho um nivel avancado de conhecimentos para lhe auxiliar.

Abracos.

PS: Gostaria de conhecer o resultados de seu teste.

>minha pergunta p/ vcs é: como vcs conduziriam estes testes?
>
>- como estressariam o database?
>- como estressariam o Webserver?
>- como estressariam o sistema operacional?
>
>agradeço a as opiniões de vcs. como sei que não é o assunto da nossa lista,
>agradeceria de me enviassem as suas idéias em pvt.
>
>assim que eu tiver os resultados em mãos estarei disponibilizando para todos
>na lista.
>
>obrigado pelo help !
>
>guilherme
>
>----
>Para sair da lista envie um e-mail para majordomo em fugspbr.org
>com as palavras "unsubscribe fugspbr" no corpo da mensagem.
>

-- 
Scotty:	Captain, we din' can reference it!
Kirk:	Analysis, Mr. Spock?
Spock:	Captain, it doesn't appear in the symbol table.
Kirk:	Then it's of external origin?
Spock:	Affirmative.
Kirk:	Mr. Sulu, go to pass two.
Sulu:	Aye aye, sir, going to pass two.
----
Para sair da lista envie um e-mail para majordomo em fugspbr.org
com as palavras "unsubscribe fugspbr" no corpo da mensagem.