zezologs» Performance http://www.zezologs.org/blog teste de software, prevenção de erros, automação Thu, 08 Sep 2011 12:49:25 +0000 en hourly 1 Definindo Requisito-Não Funcional de Performance http://www.zezologs.org/blog/definindo-requisito-nao-funcional-de-performance/ http://www.zezologs.org/blog/definindo-requisito-nao-funcional-de-performance/#comments Thu, 28 Aug 2008 12:18:39 +0000 eudescosta http://www.zezologs.org/blog/?p=316 A definição do requisito não funcional de performance é uma atividade muito particular de cada projeto de desenvolvimento, assim sendo, as preocupações variam muito de projeto em projeto. No entanto, algumas preocupações podem ser muito similares dependendo da natureza, tipo e plataforma em que a aplicação é desenvolvida.

Irei postar aqui uma lista com algumas preguntas que podem ajudar muito aqueles que necerssitam definir este requisito não-funcional, as perguntas a seguir não são “leis” e sim um guia inicial para a definição deste requisito, este questionário deverá mudar bastante contendo informações específicas do seu projeto.

Com isto em mente vamos ao questionário:

1.    Qual a quantidade de requisições simultâneas nos horários de pico?
2.    Qual a quantidade de requisições por segundo será demandada aos nossos serviços?
3.   Qual o tempo de resposta médio esperado?
4.    Quantos usuários logado no sistema a aplicação deverá suportar?
5.    Qual a importância dos testes de performance no escopo do projeto?
6.    Quais os cenários mais críticos envolvendo performance dentro da aplicação?
7.    Qual o volume médio de transações diárias? e qual o pico de demanda?
8.    Qual a taxa de crescimento de usuários prevista?
9.    Qual o tamanho médio em bytes destas transações?
10.    Qual a velocidade dos links que proverão acesso a aplicação?
11.   Quais as preocupações relacionadas a performance já existem?
12.    Qual a taxa de crescimento (estimativa) da base de dados.
13.    Existe necessidade de execução em cluster (aplicação rodando em varias instâncias).
14    Qual a configuração utilizada no servidor que hospedará a aplicação?
14.1    Quais fabricantes?
14.2    Quantos processadores têm cada servidor? caso haja mais de um.
14.3    Quando de memória RAM?
14.4    Qual o cache utilizado?
14.5    Como é implementada a segurança dos servidores?
14.6    Existe algum cluster instalado?
15.    Existe alguma solução para balanceamento de carga adotada?
Se sim:
15.1    Qual plataforma?
15.2    Qual arquitetura?
15.3    Qual o mecanismo de controle de seção?
15.4    O balanceamento é feito por hardware ou software?

Qualquer dúvida é só comentar!


comentários

  • sexta-feira, setembro 12, 2008, Elias Nogueira comentou: Eudes, Parabens! Muito bom esse questionário!!! Aproveitando, posso atualizar o documento de Questionário de Teste de Performance com estes teus pontos também? Abraço!

  • sexta-feira, setembro 12, 2008, eudescosta comentou: Opa Elias, Pode sim cara, fica a vontade! Abraço.

  • quinta-feira, setembro 8, 2011, Ferramentas de Teste: JMeter (2) | zezologs comentou: [...] aqui sobre como elicitar o requisito não-funcional de performance. Definir este requisito não é uma [...]

    • leia mais...


    Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress

    A definição do requisito não funcional de performance é uma atividade muito particular de cada projeto de desenvolvimento, assim sendo, as preocupações variam muito de projeto em projeto. No entanto, algumas preocupações podem ser muito similares dependendo da natureza, tipo e plataforma em que a aplicação é desenvolvida.

    Irei postar aqui uma lista com algumas preguntas que podem ajudar muito aqueles que necerssitam definir este requisito não-funcional, as perguntas a seguir não são “leis” e sim um guia inicial para a definição deste requisito, este questionário deverá mudar bastante contendo informações específicas do seu projeto.

    Com isto em mente vamos ao questionário:

    1.    Qual a quantidade de requisições simultâneas nos horários de pico?
    2.    Qual a quantidade de requisições por segundo será demandada aos nossos serviços?
    3.   Qual o tempo de resposta médio esperado?
    4.    Quantos usuários logado no sistema a aplicação deverá suportar?
    5.    Qual a importância dos testes de performance no escopo do projeto?
    6.    Quais os cenários mais críticos envolvendo performance dentro da aplicação?
    7.    Qual o volume médio de transações diárias? e qual o pico de demanda?
    8.    Qual a taxa de crescimento de usuários prevista?
    9.    Qual o tamanho médio em bytes destas transações?
    10.    Qual a velocidade dos links que proverão acesso a aplicação?
    11.   Quais as preocupações relacionadas a performance já existem?
    12.    Qual a taxa de crescimento (estimativa) da base de dados.
    13.    Existe necessidade de execução em cluster (aplicação rodando em varias instâncias).
    14    Qual a configuração utilizada no servidor que hospedará a aplicação?
    14.1    Quais fabricantes?
    14.2    Quantos processadores têm cada servidor? caso haja mais de um.
    14.3    Quando de memória RAM?
    14.4    Qual o cache utilizado?
    14.5    Como é implementada a segurança dos servidores?
    14.6    Existe algum cluster instalado?
    15.    Existe alguma solução para balanceamento de carga adotada?
    Se sim:
    15.1    Qual plataforma?
    15.2    Qual arquitetura?
    15.3    Qual o mecanismo de controle de seção?
    15.4    O balanceamento é feito por hardware ou software?

    Qualquer dúvida é só comentar!


    comentários

  • sexta-feira, setembro 12, 2008, Elias Nogueira comentou: Eudes, Parabens! Muito bom esse questionário!!! Aproveitando, posso atualizar o documento de Questionário de Teste de Performance com estes teus pontos também? Abraço!

  • sexta-feira, setembro 12, 2008, eudescosta comentou: Opa Elias, Pode sim cara, fica a vontade! Abraço.

  • quinta-feira, setembro 8, 2011, Ferramentas de Teste: JMeter (2) | zezologs comentou: [...] aqui sobre como elicitar o requisito não-funcional de performance. Definir este requisito não é uma [...]

    • leia mais...


    Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress ]]> http://www.zezologs.org/blog/definindo-requisito-nao-funcional-de-performance/feed/ 3 14 Regras Básicas Para Aplicações WEB http://www.zezologs.org/blog/14-regras-bsicas-para-aplicaes-web/ http://www.zezologs.org/blog/14-regras-bsicas-para-aplicaes-web/#comments Thu, 14 Aug 2008 23:57:04 +0000 eudescosta http://www.zezologs.org/blog/?p=312 Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSlow, que abordei em “Dicas: Firebug e YSlow“.

    O autor do livro e do YSlow é Steve Sounders um guru na arte e ciência de performance em aplicações WEB.

    As 14 regras são:

    Regra 1: Minimize HTTP Requests

    Problema) 80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP, requisições estas que envolvem Imagens, Scripts, CSS, Flash que são referenciados no HTML.

    Solução 01) Use Image Maps

    Imagem Maps é uma técnica que mapeia uma imagem, ao invés de carragar cada imagem individualmente como fazemos de costume, criamos uma imagem unica e mapeamos cada parte da imagem via javascript.

    Exemplos: http://stevesouders.com/examples/imagemap.php, http://en.wikipedia.org/wiki/Image_map

    Solução 02) Similar ao Image Maps só que com CSS

    Exemplo: http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/

    Regra 2: Use CDN´s (Content Delivery Network)

    Assim como descrito na 1º Regra “80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP.”

    CDN´s são servidores que hospedam conteúdo estático em servidores separados da sua aplicação, ou em caso de portais de grande porte, este conteúdo não somente é de conteúdo estático, como tambem de todo o conteúdo do site, que seria distribuído baseado na região de onde a requisições foi feita.

    Regra 3: Use “Expires Header“

    Problema) Browsers usam cache para reduzir a quantidade de HTTP requests.

    Solução) “Expires Headers” fala por quanto tempo um componente deve ser armazenado em cache.

    Regra 4: Utilize Gzip

    Problema) Excesso de HTTP Requests, causado pelos componetes de uma aplicação (imagens, css, etc)

    Solução) Comprima seus arquivos usando gzip. A maioria dos browsers disponíveis no mercado suportam compressão de aquivos via o ‘Accept-Encoding’.

    Gzip é o mais popular e eficiente método de compressão atualmente.

    Exemplos) http://www.weberdev.com/get_example-3993.html

    Regra 5: Mova CSS para o topo

    Problema) CSS no final provoca demora no carregamento da página.

    Solução) Esta prática, acredito que todos fazem a contento, pelo menos desde que comecei a trabalhar com WEB costumo por os CSS no topo, mas para aqueles que o inserem no final da página, vai ai o alerta, isso afeta o carregamento de suas páginas, a explicação é bastante óbvia, quando o browser recebe uma solicitação, ele procura primeiro quais elementos gráficos carregar para depois carregar o conteúdo da página, tornando o CSS no final um equívoco.

    Regra 6: Mova scripts para baixo

    Ao contrário do CSS, os scripts em sua maioria devem ser movidos para o final da pagina, deixando os scripts no <HEAD> podem afetar o carregamento gradual da página, movendo os scripts para final, permite a paralelização do download do conteúdo do site.

    Regra 7: Evite expressões em CSS

    Muitos utilizam expressões em CSS para definir um background-color que mudem dinamicamente, a cada hora, isso é um exemplo de uso desnecessário de expressões em CSS, neste caso, isto poderia estar em um script em javascript, php, C#, etc… .

    Regra 8: ‘Inlined’ JavaScript e CSS

    Não consegui uma tradução para esta regra, mas irei explicar do que se trata.

    ‘Inline’ Javasctipt e CSS diz respeito a incluir os CSS e o Javascript inteiro na página ao invés de deixa-los em arquivos externos, como fazemos de costume.

    Regra 9: Minimize Domínios

    Algumas aplicações precisam fazer verificações de DNS, tente reduzir isso ao máximo.

    Regra 10: Minimize JavaScript

    Trata-se de uma boa prática em relação a confecção de CSS. Esta boa prática diz respeito a nomenclatura usada nos elementos.

    Reduzir ao máximo o nome dos elementos, ou seja, fazer um refactoring no CSS.

    Regra 11: Evite Redirecionamentos

    Redirecimentos são usados para rotear uma URL para outra URL, está prática, por motivos claros reduzem o tempo de carregamento das páginas.

    Regra 12: Remova Scritps Duplicados

    Da mesma forma que temos que fazer refactoring periódicos, no código de nossas aplicações, devemos fazer refactoring  tambem no código do nosso front-end.

    Muitas vezes esquecemos que o front-end tambem tem código ;)

    Regra 13: Desabilite ETags

    ETags é um mecanismo que webservers e browsers usam para determinar se o componente do cache do browser combina com com o que está no servidor.

    O problema com ETags é qu eles são tipicamente construidos usando atributos que os tornam únicos para o servidor que hospeda o site, logo eles nunca vão combinar com o cache do browser.

    Regra 14: Cache AJAX

    Como a própria regra fala, permita que o AJAX utilize o cache so seu browser

    Todos os exemplos acima estão muito bem organizados aqui, o autor destas regras é o Steve Sounders, eu apenas traduzi para o português algumas partes importantes das 14 regras.

    Estas regras, não se aplicam em todos os casos, mas é importante termos a consciência de que elas existem e que a não adoção de muitas destas regras, implicará em redução da performance de sua aplicação.


    comentários

  • sexta-feira, agosto 15, 2008, Eudes via Rec6 comentou: 14 Regras Básicas Para Aplicações WEB | ...zezologs... Lista de 14 regras a serem utilizadas em projetos de desenvolvimento de aplicações WEB. ...

  • domingo, agosto 17, 2008, eudescosta no diHITT comentou: 14 Regras Básicas Para Aplicações WEB ... Lista de 14 regras definidas por Steve Sounders, a serem utilizadas em projetos de desenvolvimento de aplicações WEB visando a melhoria da performance do produto final. ...

  • domingo, agosto 17, 2008, www.digga.com.br comentou: 14 Regras Básicas Para Aplicações WEB... Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSl...

  • quarta-feira, agosto 20, 2008, Silvio Blauth comentou: ≈up≈

  • terça-feira, outubro 28, 2008, Claudio comentou: ≈up≈ Valeu!! Muito bom!

  • quarta-feira, junho 1, 2011, Antonio carlos comentou: ≈up≈

    • leia mais...


    Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress

    Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSlow, que abordei em “Dicas: Firebug e YSlow“.

    O autor do livro e do YSlow é Steve Sounders um guru na arte e ciência de performance em aplicações WEB.

    As 14 regras são:

    Regra 1: Minimize HTTP Requests

    Problema) 80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP, requisições estas que envolvem Imagens, Scripts, CSS, Flash que são referenciados no HTML.

    Solução 01) Use Image Maps

    Imagem Maps é uma técnica que mapeia uma imagem, ao invés de carragar cada imagem individualmente como fazemos de costume, criamos uma imagem unica e mapeamos cada parte da imagem via javascript.

    Exemplos: http://stevesouders.com/examples/imagemap.php, http://en.wikipedia.org/wiki/Image_map

    Solução 02) Similar ao Image Maps só que com CSS

    Exemplo: http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/

    Regra 2: Use CDN´s (Content Delivery Network)

    Assim como descrito na 1º Regra “80-90% do tempo navegando em uma página WEB é gasto em requisições HTTP.”

    CDN´s são servidores que hospedam conteúdo estático em servidores separados da sua aplicação, ou em caso de portais de grande porte, este conteúdo não somente é de conteúdo estático, como tambem de todo o conteúdo do site, que seria distribuído baseado na região de onde a requisições foi feita.

    Regra 3: Use “Expires Header“

    Problema) Browsers usam cache para reduzir a quantidade de HTTP requests.

    Solução) “Expires Headers” fala por quanto tempo um componente deve ser armazenado em cache.

    Regra 4: Utilize Gzip

    Problema) Excesso de HTTP Requests, causado pelos componetes de uma aplicação (imagens, css, etc)

    Solução) Comprima seus arquivos usando gzip. A maioria dos browsers disponíveis no mercado suportam compressão de aquivos via o ‘Accept-Encoding’.

    Gzip é o mais popular e eficiente método de compressão atualmente.

    Exemplos) http://www.weberdev.com/get_example-3993.html

    Regra 5: Mova CSS para o topo

    Problema) CSS no final provoca demora no carregamento da página.

    Solução) Esta prática, acredito que todos fazem a contento, pelo menos desde que comecei a trabalhar com WEB costumo por os CSS no topo, mas para aqueles que o inserem no final da página, vai ai o alerta, isso afeta o carregamento de suas páginas, a explicação é bastante óbvia, quando o browser recebe uma solicitação, ele procura primeiro quais elementos gráficos carregar para depois carregar o conteúdo da página, tornando o CSS no final um equívoco.

    Regra 6: Mova scripts para baixo

    Ao contrário do CSS, os scripts em sua maioria devem ser movidos para o final da pagina, deixando os scripts no <HEAD> podem afetar o carregamento gradual da página, movendo os scripts para final, permite a paralelização do download do conteúdo do site.

    Regra 7: Evite expressões em CSS

    Muitos utilizam expressões em CSS para definir um background-color que mudem dinamicamente, a cada hora, isso é um exemplo de uso desnecessário de expressões em CSS, neste caso, isto poderia estar em um script em javascript, php, C#, etc… .

    Regra 8: ‘Inlined’ JavaScript e CSS

    Não consegui uma tradução para esta regra, mas irei explicar do que se trata.

    ‘Inline’ Javasctipt e CSS diz respeito a incluir os CSS e o Javascript inteiro na página ao invés de deixa-los em arquivos externos, como fazemos de costume.

    Regra 9: Minimize Domínios

    Algumas aplicações precisam fazer verificações de DNS, tente reduzir isso ao máximo.

    Regra 10: Minimize JavaScript

    Trata-se de uma boa prática em relação a confecção de CSS. Esta boa prática diz respeito a nomenclatura usada nos elementos.

    Reduzir ao máximo o nome dos elementos, ou seja, fazer um refactoring no CSS.

    Regra 11: Evite Redirecionamentos

    Redirecimentos são usados para rotear uma URL para outra URL, está prática, por motivos claros reduzem o tempo de carregamento das páginas.

    Regra 12: Remova Scritps Duplicados

    Da mesma forma que temos que fazer refactoring periódicos, no código de nossas aplicações, devemos fazer refactoring  tambem no código do nosso front-end.

    Muitas vezes esquecemos que o front-end tambem tem código ;)

    Regra 13: Desabilite ETags

    ETags é um mecanismo que webservers e browsers usam para determinar se o componente do cache do browser combina com com o que está no servidor.

    O problema com ETags é qu eles são tipicamente construidos usando atributos que os tornam únicos para o servidor que hospeda o site, logo eles nunca vão combinar com o cache do browser.

    Regra 14: Cache AJAX

    Como a própria regra fala, permita que o AJAX utilize o cache so seu browser

    Todos os exemplos acima estão muito bem organizados aqui, o autor destas regras é o Steve Sounders, eu apenas traduzi para o português algumas partes importantes das 14 regras.

    Estas regras, não se aplicam em todos os casos, mas é importante termos a consciência de que elas existem e que a não adoção de muitas destas regras, implicará em redução da performance de sua aplicação.


    comentários

  • sexta-feira, agosto 15, 2008, Eudes via Rec6 comentou: 14 Regras Básicas Para Aplicações WEB | ...zezologs... Lista de 14 regras a serem utilizadas em projetos de desenvolvimento de aplicações WEB. ...

  • domingo, agosto 17, 2008, eudescosta no diHITT comentou: 14 Regras Básicas Para Aplicações WEB ... Lista de 14 regras definidas por Steve Sounders, a serem utilizadas em projetos de desenvolvimento de aplicações WEB visando a melhoria da performance do produto final. ...

  • domingo, agosto 17, 2008, www.digga.com.br comentou: 14 Regras Básicas Para Aplicações WEB... Recebi uma indicação de Saulo Dourado, designer gráfico do CESAR, de um livro chamado “High Performance Web Sites” que contém uma lista de 14 “regras” para o desenvolvimento de frontends eficientes, estas mesmas 14 regras são usadas no YSl...

  • quarta-feira, agosto 20, 2008, Silvio Blauth comentou: ≈up≈

  • terça-feira, outubro 28, 2008, Claudio comentou: ≈up≈ Valeu!! Muito bom!

  • quarta-feira, junho 1, 2011, Antonio carlos comentou: ≈up≈

    • leia mais...


    Copyright © 2007-2008 zezologs.org | Todos os direitos reservados | Acessibidade | WordPress ]]> http://www.zezologs.org/blog/14-regras-bsicas-para-aplicaes-web/feed/ 6