Problemas de Performance

[Nando Sousa]

Fala galera, tudo bom?

Tenho uma app no heroku com cerca de 3 milhoes se pageviews/mês, 90 % dos requests são

provenientes da busca:

http://www.soprojetos.com.br/ver-projetos/plantas

Além de cache, utilizo elasticsearch para indexar e buscar informações do projeto.

Atualmente a app roda em 2 dinos (2x) no heroku, em média são 97 pessoas acessando simultaneamente. 

Infelizmente estou tendo muitos request timeout e memory quota exceded.

Minhas perguntas são:

1) O número de dynos está correto para uma app nos critérios acima?

2) O que estou fazendo errado? algum conselho?

Obrigado :)

—
Sent from Mailbox

[Alexandre Cardoso]

Oi Nando.

Você consegue dar mais detalhes sobre a arquitetura da sua aplicação (MRI/JRuby/whatever, componentes de frontend e backend, servidor de banco e aplicação, etc)?

Se seus clientes estão tomando muito request timeout, só pode significar que sua aplicação está demorando a servir a resposta HTTP aos respectivos requests. Isso acontece em todos os cenários funcionais da aplicação? Consegue isolar onde isto acontece?

Sobre "memory quota exceded", eu já tive algumas situações onde uma configuração errada no unicorn (no workers) levou a um consumo elevado de memória (mais forks = mais memória), na tentativa de escalar o uso. Além disso, pode estar havendo uma pressão sobre a memória do processo da aplicação, no sentido de haver muitas instâncias de objetos sendo produzidas e pouca oportunidade para o garbage collector trabalhar. Aí já estou falando um pouco sobre o que acontece no Java, onde trabalho mais. Mas sei que o Ruby tb tem patterns assim.

Enfim, se você puder, descreva melhor a arquitetura da sua aplicação e o grupo pode lhe ajudar melhor.

Abs.

--
You received this message because you are subscribed to the Google Groups "guru-pa" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guru-pa+u...@googlegroups.com.
To post to this group, send email to gur...@googlegroups.com.
Visit this group at http://groups.google.com/group/guru-pa.
For more options, visit https://groups.google.com/d/optout.

[Nando Sousa]

Olá, Alexandre

Muito obrigado pela resposta,

O problema é realmente nessa página de busca.

segue informações:

Ruby MRI 2.1.0

Js: AngularJS

Servidor Banco de Dados: Heroku Postgres

SearchEngine: Elasticsearch

configuração do unicorn:

# see https://gist.github.com/leshill/1401792

worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3)

timeout Integer(ENV['UNICORN_TIMEOUT'] || 3)

preload_app true

before_fork do |server, worker|

  # Replace with MongoDB or whatever

  if defined?(ActiveRecord::Base)

    ActiveRecord::Base.connection.disconnect!

    Rails.logger.info('Disconnected from ActiveRecord')

  end

  # If you are using Redis but not Resque, change this

  if defined?(Resque)

    Resque.redis.quit

    Rails.logger.info('Disconnected from Redis')

  end

end

after_fork do |server, worker|

  # Replace with MongoDB or whatever

  if defined?(ActiveRecord::Base)

    ActiveRecord::Base.establish_connection

    Rails.logger.info('Connected to ActiveRecord')

  end

  # If you are using Redis but not Resque, change this

  if defined?(Resque)

   Resque.redis = ENV['REDIS_URL']

    Rails.logger.info('Connected to Redis')

  end

end

Sds,

Nando Sousa

Seo e Desenvolvedor Ruby

(55) 93 9109-8215

skype: nandosousafr

[Nando Sousa]

Só corrigindo :)

essa parte é assim e não a anterior.

timeout Integer(ENV['UNICORN_TIMEOUT'] || 30)

[Jairo Junior]

Fica difícil dá uma resposta precisa sem mais detalhes. É como você chegar no médico e dizer que está com febre, sem dizer quando começou, se vem e volta, variação de graus, se é a primeira vez, etc..

1) Você provavelmente vai ser a pessoa mais indicada para dá essa resposta quando observar como sua aplicação escala. Alguém poderia dizer para você dobrar esse número, mas o que você aprenderia sobre a sua aplicação?

2) Estás usando alguma ferramenta de monitoramento real time, como NewRelic, ou AppDynamics? Caso não esteja, seria bom começar a utilizar e vê o quanto elas vão te ajudar a identificar gargalos em produção.

Cache não é a solução para todos os problemas, ele pode inclusive está escondendo a origem desse timeout. Imagine o seguinte cenário: um usuário está acostumado com respostas rápidas, então o cache expira e as respostas começam a ficar mais lentas que o normal, usuário começa a pressionar f5, multiple isso pelo total de usuários e esse é o tamanho do seu problema.

O que seus testes de desempenho estão lhe dizendo? Se não tiver nenhum, tá na hora de começar com um teste de carga, pico, estresse, soak... Pelo menos para as principais transações. Se a sua API for HTTP, em pouquíssimo tempo você monta isso com o JMeter.

Fiz 50 requisições simultâneas para aquela link que você mandou e tive um tempo de resposta médio de 1.4s, quando aumentei para 100 requisições simultâneas, esse tempo pulou para 3.1s. O que isso quer dizer? Não muita coisa. Não tem jeito, você tem que investigar e trazer os sintomas. 

Podes dobrar o poder de processamento e ainda ter o mesmo problema, se for algum tipo de contenção, até porque, todos os computadores esperaram na mesma velocidade.

[caike]

Como pessoal já comentou, uma ferramenta de análise de performance (i.e. NewRelic RPM) pode ajudar a descobrir onde exatamente é o gargalo.

Regards,
- Carlos