[Resolvido] Server - Load Average

[mauroagr]

Pessoal, 

Estou rodando o prestashop 1.5.6.1 rodando em um VPS com 4 nucleos, RAM: 1024MB, cache ativo (arquivos do sistema), ccc, etc..etc.

Quando tenho pouco usuario é um tiro, super rapido, perfeito.

Agora, por exemplo, tenho 7 usuario, baseado no analitics, load average: 2.08, 1.94, 1.82, isto as 23.00, estaria tranquilo.

Agora durante o dia, com picos de 30 ou 35 usuarios, o load vai acima de 8.00, ou seja, tenho fila de processamento, e isto me leva a necessidade de aumentar processador.

 

To achando que tem alguma coisa errada, pois com 70 usuario vai travar tudo, o que acho inviavel o uso do prestashop.

 

Alguem tem alguma ideia de como resolver, ou puder ajudar agradeço.

Site: www.usinainfo.com.br

 

Abraço,

Mauro

Edited April 24, 2014 by mauroagr (see edit history)

[selectshop.at]

O maior problema sao as suas imagens. Ou vc. comprime antes de subí-las ao servidor (RIOT por. ex. vc. encontra grátios na net), ou vc. pensa em usar um servidor extra para as suas medias. Veja o screen anexo e este link de análise. TTFB (time to first byte) é um problema de servirodres mal configurados: http://www.webpagetest.org/result/140411_1Z_6KR/1/details/

 

O módulo google analytics que está usando também toma um monte de tempo para carregar.

Edited April 11, 2014 by selectshop.at (see edit history)

[mauroagr]

Bom dia Selectshop,

Entendo que pode ser o ttfb.

Mas meu problema, neste exato momento nao estou focado nisto.

Meu problema é que quando tem uns 30 usuario o presta tá demandando bastante processamento, e se for nesta proporção, com tá dando 9 usuario por nucleo, o que é 'inviavel' financeiramente.

Já acompanhei as consultas, e testei um monte de possibilidades.

Qual a configuração de um server de 4 nucleos para atender 100 usuario, que você conhece, ou tenha experiencia.

Att,

Mauro

[Daniel - PrestaBR]

Não é muito simples debugar o load do servidor...

Podem ser vários fatores e nem sempre é fácil descobrir o motivo exato da sobrecarga.

 

Eventuais erros de PHP ou consultas MySQL lentas podem causar load alto também.

Para uma página com menos de 1MB não era pra ter um load tão alto.

 

Recomendo que analise cada módulo não nativo.

Se possível desinstale de um por um (dependendo do módulo, desabilitar apenas não resolve), testando o load por alguns minutos a cada módulo desinstalado.

 

Fora isso, precisa verificar as configurações do servidor para se certificar que está bem configurado.

Verifique as configurações do PHP, eventuais módulos não utilizados, etc...

Verifique também se o banco de dados está consistente, com o mesmo motor do banco e das tabelas.

 

Após verificar tudo, pode ativar o memcached e, se for uma opção, servidores de mídia em subdomínios (se tiver SSL habilitado vai precisar de um certificado SSL WildCard).

 

Existem várias dicas para melhorar a performance de um servidor e do MySQL. Dá uma pesquisada no Google.

 

Boa sorte.

[mauroagr]

Boa Tarde Daniel,

Concordo contigo que debugar é um inferno! O que noto é que vem tudo bem...e ai parece que 'tranca' e ai dá fila...e o load vai para cima.

Estou com o pessoal do servidor analisando também, porém como o load anda 'comportado' na maior parte do tempo, fica complicado de achar o furo.

Também pode ser módulo e tal, a questao é que tenho um clone do site, em outro dominio, com o debug ativo e o load time dá abaixo de 500ms, dentro do que eu esperava.

Uma dúvida, vocês tem usado o presta em php5.2 ou 5.4, teria isto impacto no desempenho à este ponto?

Att

Mauro

[selectshop.at]

Se vc. for verificar o tráfico de cada uma de suas páginas o load principal de sua página se compoe de imagens que sao a maior carga. Independente dos usuários. Cada usuário a mais é um menos para a sua carga. Vc. deveria usar o cache ou um servidor de mídia para as suas imagens.

Usando servidores mídia, vc. vai term um speed maior, pois o efeito é o mesmo que com cache. Com servidor de mída o load será distribuído por dois ou mais servidores trabalhando em conjunto.

O seu servidor trabalha com opcode cache ou load balancer ?

 

O seu time to first byte problem (TTFB) é um problema muito complexo e um debug aqui muito intensivo, porém nao impossível. Faca como o Daniel sugeriu. Tente primeiro eliminar módulos que necessitam muito tempo para executar o código.

 

Vc. fez algumas alteracoes no ficheiro .htaccess ?

Está carregando os seus produtos por um servico de terceiros em vez do banco de dados do Prestashop ? Cada task extra necessita de tempo, em conjunto acaba dando um overload quando mais de um task ou um X de tasks for aberto.

 

Os logs de erro do seu servidor estao limpos ?

 

PS 1.5 somente com php 5.3+. PS 1.6. aconselho usar php 5.4. e mysql 5.5. para uma performance ideal.

Edited April 12, 2014 by selectshop.at (see edit history)

[mauroagr]

Bom dia Selectshop,

Olha o negocio é estranho, ontem refiz algumas consultas do mysql que estavam rodando varias vezes sem necessidade.

Alterações no htaccess, nao fiz, somente o do prestashop.

Quanto ao log, ele impactaria no painel e não no site, e independente disto está com 4000 linhas. No meu sistema proprio, anterior, eu tenho um log com 35milhoes de linhas (7,5GB de mysql) e tudo rodava 100%.

Tenho alguns duvidas, que são tiros no escuro, trabalho a mais de 10 anos com php, e to usando prestashop a menos de 1 ano, então podem parecer besta, mas vamos lá.

1. Ao criar outras pastas dentro do public_html, isto impacta no processamento do prestashop, ele executa alguma 'varredura', no public_html inteiro, ou não tem logica, pois tenho pastas de outros sistemas que coloquei dentro.

2. Carga de produtos, clientes e fotos feitas via webservice, podem causa degradação da velocidade de processamento?

3. Se fosse um sobrecarga num override por exemplo, isto apareceria no debug/profiles e obviamente impactaria no load total da pagina com baixo numero de usuários? ou seja, se tenho uma load de menos 500ms (eu considero suficiente, lembrando que estou no brasil e o server tmb está aqui)
4. Você tem algum cliente/exemplo de site que tem 30 a 40 usuario ao mesmo tempo online, que tipo de servidor este cliente usa?

PS: estou usando php5.2, devido a necessidade para meu ERP, porém irei modificar isto, porém não acredito que irá 'solucionar' meu problema.

 

Grato pela ajuda e vamos continuar a busca.

Abraço,

Mauro

[selectshop.at]

Cada linha de erro é uma linha inútil e deve ser analisada e eliminda. Tudo em suma custa-lhe um monte de tempo no load.

 

Quanto ao seu ponto 1. Isto depende tudo da outra software que está usando. Um é certo. Cada software tem o seu ficheiro .htaccess próprio. Vc. colocando tudo em um pasta só com um .htaccess enorme isto lhe custa tempo, pois cada linha deste ficheiro terá de ser lida, interpretadad e executada. Para cada software a linha que lhe foi escrita. Melhor vc. dividir tudo em pastas diferentes. Para cada software a sua pasta. Eu conheco este problema, pois acabei de migrar para um servidor mais barato. O que foi que eu fiz. Deixei o domínio que usa a software menos problemática (neste caso word press) no root. Os outros domínios (todos eles Prestashop) coloquei cada um em uma pasta própria. Assim o public_html fica arrumadinho e nenhuma software interfere com a outra.

 

Quanto ao seu ponto 2. Se vc. for carregar de fora é obvio que é um passo a mais e isto faz com que retarde o load completo. Qual o caminho mais curto ? Diretamente do banco de dados do Prestashop, ou através de um script a mais carregando de um banco de dados externo ? Ou comparando com uma escada em forma caracol e um elevador de linha direta. O que é mais rápido ? Vc. ter que correr em caracol ou vc. indo através da linha direta ?

 

 

Qual debug vc. está usando para verificar os seus problemas. Aquele ativando a linha no ficheiro /cvonfig/config.inc.php ? Isto somente ativa os erros que dá, mas nao deixa verificar nada em questao de SQL queries. Para verificar problemas no banco de dados vc. pode ativar no seu back-office na aba "parametros avancados -> desempenho -> console de depuracao = sempre console aberto. Cada query que for fazer vai abrir uma janela e vc. pode verificar aonde está dando problema. É isso que está usando ?

 

PHP 5.2. é uma versao já ulptrapassada que nao suporta Prestashop. Porque nao?  Vc. com Prestashop tem um mercedes e obriga este de nao ultrapassar dos 100, colocando uma gasolina barata. Prestashop trabalha com a técnica mais atual, O problema de versoes php antigas, é que alguns comandos novos nao podem ser interpretados, pois eles lá simplesmente nao existem (sao ignorados). Assim como muitos comandos/módulos inúteis que custam tempo no load (magic_quotes, safe_mode, etc) ainda continuam sendo carregados no servidor porcausa de versoes php antigas.

 

Use php 5.4 e o que é mais importante uma versao SQL atual. mysql 5.5. é uma versao muito rápida. Eu fiz uma comparacao com a minha loja de 10.000 produtos com a versao mySQL 5.3. e 5.5. É dia e noite. 5.5. trabalha muito mais rápido com Prestashop 1.5. e 1.6. O ganho é de 1/3 !! com o mesmo servidor. O meu provedor tem próprios servidores optimizados para banco de dados, assim é possível vc. trocar entre versoes para experimentar.

 

Nesta minha loja de 10.000 produtos tenho por dia aproximadamente 2.000 visitantes, sendo que se acham mais ou menos 20 visitantes ao mesmo tempo (fora as máquinas de busca). O load aqui nunca, independente de quantos visitantes tem, ultrapassa dos 3 segundos por task. O meu servidor na verdade é um servidor trabalhando em conjunto com vários servidores distribuíndo o load por várias máquinas. O banco de dados se encontra em um servidor próprio optimizado para banco de dados.

Foi por isso que eu perguntei se o seu servidor trabalha com opcode cache e load balancer. Nem todo provedor oferece este tipo de "network..."

Vc. deveria tentar um CDN ou cloud para melhor distribuir o load se nao tiver possibilidade de usar APC cache ou outro tipo de cache. Mas por favor nao use o filecache (cache interno), porque este dá um monte de erros. No comeco ele parece trabalhar bem, mas assim que a pasta /cache vai crescendo acaba dando um monte de outros problemas com módulos e features do Prestashop.

[mauroagr]

Pessoal,

Desabilitei o cacheFS e vou aguardar na segunda feira, para analisar o comportamento, com fluxo de pessoas.

O CDN não vou considerar por enquanto, pois acredito que a mais velocidade nao é meu problema, pois enquanto o processamento dá conta, vai tudo tranquilo.

 

Referente às pastas, nenhum dos scripts usa .htaccess dentro do public, são scripts de tickets e livezilla, nada de anormal, ambos já rodavam anteriormente.

 

Sobre a carga de produtos, acho que me expliquei mal, eu fiz o casdatramento inicial via webservice do prestashop, somente isto, nada de mais!

 

Duvida: tenho o cache e o tipo de sistema de cache? ambos tecnicamente são independentes! posso ter o cache ativo e sistema de cache desativado? como é este comportando no 'campo de guerra'...ehheheeh

 

Esta discussão tá ficando legal, obrigado pelas opiniões e ajudas.

 

Abraço a todos.

Mauro

[selectshop.at]

Mauro, veja aqui o que estou querende te explicar:

 

It is always a good idea to keep an eye on how many queries your website is producing every time somebody opens a page. A general, good rule of thumb is having between 10 and 30 queries per page. Remember, the more queries your website produces, the more it consumes server resources. To find out the number of queries your website has got, insert this piece of code within your theme: <?php echo $wpdb->num_queries; ?> <?php _e(‘queries’); ?>. <?php timer_stop(1); ?> <?php _e(‘sec.’); ?> . This code will display the number of queries the page is producing and the time to process them.

 

E é justamente o que eu quero te dizer quanto às suas imagens. A sua página está carregando em cada task um monte de queries ao mesmo tempo confira com o link do web-pagetest que anexei mais acima. Quanto mais uma única página carrega, quanto mais load vc. está consumindo. A sua opcao seria: usar um servidor de mídia para as suas imagens. Vc. retirando estes queries do seu servidor. colocando em servidor próprio, estará compartilhando o load em dois servidores, ou seja diminui/divide o load.

 

Quanto ao cache. Entendo o problema, pois ele é meio complicado para que nao é expert.

Prestashop usa um monte de possibilidades de aceleracao. Prestashop tem um pequeno cache interno aonde por ex. fica guardado o cache do smarty (sao as pastas /cache que vc. encontra no seu FTP). Ao mesmo tempo vc. tem como opcao extra a possibilidade de ativar o CCC que nada mais é do que usar compressao e cache em servidores que permitem vc. usar compressao. Esta técnica funciona perfeitamente a partir da versao PHP 5.3.

Veja aqui uma explicacao mais minunciosa de um dos usuários/agencia de servicos do fórum ingles: http://www.inmotionhosting.com/support/edu/prestashop-15/advanced-parameters/combine-compress-cache

 

Além da opcao CCC, vc. ainda tem uma terceira opcao, que é ativar no servidor um módulo que cuida especialmente do cache. Este módulo pode ser: APC, X-Cache ou outro. Se um destes módulos estiver ativado vc. acima das duas outras opcoes pode também usá-lo/ativá-lo para ter uma melhor performance sem overload.

 

Além das opcoes citadas ainda existe uma outra opcao que já vem ativada na base de servidores optimizados (ZEND opcode cache):

o meu servidor por ex. nao tem um módulo cache extra ativado, mas ele trabalha já na base com opcode cache e load balancer para evitar que nos hosts virtuais se produzam peaks que  interfiram no sistema todo. O problema é que um servidor assim configurado é caríssimo e difícil de encontrar. Em suma o preco que vc. paga por um webspace, reflete no que vc. acaba recebendo.

 

Veja aqui um artigo comparando opcode cache com suhosin cache: http://www.prestashop.com/blog/en/your-prestashop-store-is-twice-as-fast-with-zend-opcache/. Lá ele compara com a versao php 5.5. O meu servidor já trabalha com ZEND opcode-cache na versao php 5.3 sem problemas. Como vc. ve também aqui a versao php faz uma diferenca, voltando à comparacao do mercedes com gasolina barata e speed limitado em 100.

 

Espero que com os links anexados eu consegui explicar as suas dúvidas.

Edited April 15, 2014 by selectshop.at (see edit history)

[selectshop.at]

Eu queria acrescentar um link ao meu post anterior, mas estou colocando o link extra:

 

https://support.cloud.engineyard.com/entries/26902267-PHP-Performance-I-Everything-You-Need-to-Know-About-OpCode-Caches

[mauroagr]

Bom dia,

No final de semana, fiz algumas otimizações de consultas sql para reduzir o numero, e estou tendo bons resultados até o momento.

Tenho um modulo, o tal de csmegamenu, nativo do tema. Otimizei um monte de consultas na base, porém ele 'reconsulta' todas as categorias na parte responsiva, e ai que deve estar atolando o servidor, mas ainda não me deu tempo de otimizar esta parte.

A migração para outra versão do php, estou trabalhando e posto novidades.

Desabilitei o cache de arquivos e o desempenho melhorou bastante, aumentei a capacidade do numero de usuarios, mas ainda acho que dá para melhorar mais ainda.

Posto novidades em breve. 

Obrigado Selectshop.at e Daniel.

Att

Mauro

[mauroagr]

Pessoal,

Após alguns dias de tensão e sem muita coisa para fazer, consegui reduzir abusrdamente o processamento.

ABaixo o que realizei.

1. Desativei o cacheFS (cache de arquivos), deixei somente o cache do smarty e os CCC.

2. Otimizações 'fortes' nas consultas SQL no CSmegamenu do template e CShomefeatured, que estava consultando umas bobagens, inuteis.

3. Atualizei o VPS para php 5.3;

4. Acendi umas velas para isto solucionar...hehehe

 

e para minha surpresa, a cada dia que passa mais reduz o load, hoje com 35 usuarios, roda com 0.80, em média, ou seja, completamente aceitavel, melhor que isto, acho que é impossivel.

 

Obrigado à todos, e um obrigado especial ao Selectshop.at e ao Daniel pelo tempo, tentando ajudar.

 

Att

Mauro

[selectshop.at]

O problerma do mega-menu eu concheco. Estava usando este módulo em uma das minhas próprias páginas. O desenvolvedor estava ciente do problema de load em todas as páginas. Eu pedi a ele fixar. Negativo tento um monte de vezes e nada. Acabei pedindo o meu dinheiro de volta e comprei outro módulo sem o problema.

 

O cacheFs funciona até um certo ponto, depois comeca a dar um monte de problemas e finalmente faz com que a página fique lenta. É um problema conhecido que nunca foi debugado. Porque ainda oferecem esta opcao eu nao sei te dizer. Já briguei com os desenvolvedores porcausa deste feature, mas simplesmente ignoram. No fórum ingl°es vc. vai encontrar alguns tópicos com os problemas com o cache através do arquivo do sistema.

 

Fico feliz que conseguiu resolver o problema ao menos para a sua satisfacao.

[mauroagr]

​O Megamenu, veio junto no thema, entao veio no pacote..hehehe..mas como sou 'macac​o véio' em programação entrei no codigo, e melhorei.

Ainda não consegui otimizar a parte do megamenu para responsivo, pois ele carrega duas vezes as categorias, mas por enquanto tá rodando bem.

 

Quanto a cacheFS, será que vai ter melhoras nele, por que segundo a analise do meu pessoal do server, os caches melhoram, mas não compensa o beneficio, e tal..mas nao sei, nunca consegui testar um e outro.

 

To agora pensando numa migracao para a 1.6, mas vou esperar sair umas versoes para 'estabilizar' mais, pois devem haver alguns problemas ocultos como to projeto novo.

 

Precisando de algo, somente entrar em contato.

 

Abraço,

Mauro